Re: order by slowing down a query by 80 times

From: Tom Lane
Subject: Re: order by slowing down a query by 80 times
Date: ,
Msg-id: 3371.1277756338@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: order by slowing down a query by 80 times  (Rajesh Kumar Mallah)
List: pgsql-performance

Tree view

order by slowing down a query by 80 times  (Rajesh Kumar Mallah, )
 Re: order by slowing down a query by 80 times  (Yeb Havinga, )
  Re: order by slowing down a query by 80 times  (Andres Freund, )
  Re: order by slowing down a query by 80 times  (Rajesh Kumar Mallah, )
 Re: order by slowing down a query by 80 times  ("Kevin Grittner", )
  Re: order by slowing down a query by 80 times  (Tom Lane, )
   Re: order by slowing down a query by 80 times  (Rajesh Kumar Mallah, )
   Re: order by slowing down a query by 80 times  (Rajesh Kumar Mallah, )
    Re: order by slowing down a query by 80 times  (Tom Lane, )

Rajesh Kumar Mallah <> 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


pgsql-performance by date:

From: Bruce Momjian
Date:
Subject: Re: PostgreSQL as a local in-memory cache
From: Robert Haas
Date:
Subject: Re: PostgreSQL as a local in-memory cache