On 08/02/13 01:52, Stefan Keller wrote:
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.
If you havent done it .. bump up statistics target on the column and re-analyze, see what that gives. I have also been playing with the cost-numbers in order to get it to favour an index-scan more often. That is lowering random_page_cost to be close to seq_page_cost, dependent on your system, the amount of memory, etc, then this can have negative side-effects on non-gin-queries. -- Jesper -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
