From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: order by slowing down a query by 80 times |
Date: | 2010-06-28 20:18:58 |
Message-ID: | 3371.1277756338@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-06-28 21:44:33 | Re: cpu bound postgresql setup. |
Previous Message | Rajesh Kumar Mallah | 2010-06-28 19:56:50 | Re: order by slowing down a query by 80 times |