Rajesh Kumar Mallah <mallah.raj...@gmail.com> writes:
> co_name_vec is actually the auxiliary tsvector column that is mantained via
> a
> an update trigger. and the index that you suggested is there .
Well, in that case it's just a costing/statistics issue. The planner is
probably estimating there are more tsvector matches than there really
are, which causes it to think the in-order indexscan will terminate
earlier than it really will, so it goes for that instead of a full scan
and sort. If this is 8.4 then increasing the statistics target for the
co_name_vec column should help that. In previous versions I'm not sure
how much you can do about it other than raise random_page_cost, which is
likely to be a net loss overall.
regards, tom lane
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
