Hello you can try to wrap searching to immutable function and use following trick http://postgres.cz/wiki/PostgreSQL_SQL_Tricks#Using_IMMUTABLE_functions_as_hints_for_the_optimizer Regards Pavel Stehule 2013/2/8 Stefan Keller <sfkeller@xxxxxxxxx>: > Hi, > > I have problems with the performance of FTS in a query like this: > > SELECT * FROM FullTextSearch WHERE content_tsv_gin @@ > plainto_tsquery('english', 'good'); > > It's slow (> 30 sec.) for some GB (27886 html files, originally 73 MB zipped). > The planner obviously always chooses table scan: http://explain.depesz.com/s/EEE > I have to check again, if I'm doing something wrong but I'm pretty > sure it has to do with de-toasting and (wrong?) cost estimations. > > I've seen some comments here saying that estimating detoasting costs > (especially with operator "@@" and GIN index) is an open issue (since > years?). > And I found a nice blog here [1] which uses 9.2/9.1 and proposes to > disable sequential table scan (SET enable_seqscan off;). But this is > no option for me since other queries still need seqscan. > Can anyone tell me if is on some agenda here (e.g. as an open item for >9.2)? > > Yours, Stefan > > [1] http://palominodb.com/blog/2012/03/06/considerations-about-text-searchs-big-fields-and-planner-costs > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance