Rajesh Kumar Mallah <mallah.rajesh@xxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
