jesper@krogh.cc wrote:
>
> So getting them with AND inbetween gives x100 better performance. All
> queries are run on "hot disk" repeated 3-5 times and the number are from
> the last run, so disk-read effects should be filtered away.
>
> Shouldn't it somehow just do what it allready are capable of doing?
I'm guessing to_tsquery(...) will produce a tree of search terms (since
it allows for quite complex expressions). Presumably there's a standard
order it gets processed in too, so it should be possible to generate a
more or less efficient ordering.
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.
So - there would either need to be:
1. Some hooks from the planner to reach into the tsquery datatype.
2. A variant to_tsquery_with_sorting() which would take the column-name
or something and look up the stats to work against.
#1 is the better solution, but #2 might well be simpler to implement as
a work-around for now.
--
Richard Huxton
Archonet Ltd
