jesper@xxxxxxxx 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
