jesper@xxxxxxxx wrote: >> That structure isn't exposed to the planner though, so it doesn't >> benefit from any re-ordering the planner would normally do for normal >> (exposed) AND/OR clauses. >> >> Now, to_tsquery() can't re-order the search terms because it doesn't >> know what column it's being compared against. In fact, it might not be a >> simple column at all. > > I cant follow this logic based on explain output, but I may have > misunderstood something. The only difference in these two query-plans is > that we have an additional or'd term in the to_tsquery(). Hmm - I've had a poke through the source. I've slightly misled you... > What we see is that, the query-planner indeed has knowledge about changes > in the row estimates based on changes in the query to to_tsquery(). Yes, new in 8.4 - sorry, thought that hadn't made it in. The two plan-nodes in question are in: backend/executor/nodeBitmapIndexscan.c backend/executor/nodeBitmapHeapscan.c The actual tsearch stuff is in src/backend/utils/adt/ts*.c It looks like TS_execute (tsvector_op.c) is the bit of code that handles the tsquery tree. That uses a callback to actually check values (checkcondition_gin). The gin_extract_tsquery function is presumably the extractQuery function as described in the manuals (Ch 52). So, I'm guessing you would want to do is generate a reduced query tree for the indexscan (A & B & C => A if A is an uncommon word) and use the full query tree for the heap check. Now, what isn't clear to me on first glance is how to determine which phase of the bitmap scan we are in. HTH Just checking, because I don't think it's useful in this case. But, you don know about "gin_fuzzy_search_limit"? -- Richard Huxton Archonet Ltd -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
