jesper@krogh.cc 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