Re: quickly getting the top N rows

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Ben <bench(at)silentmedia(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: quickly getting the top N rows
Date: 2007-10-04 21:04:53
Message-ID: 21101.1191531893@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Ben <bench(at)silentmedia(dot)com> writes:
> On Thu, 4 Oct 2007, Simon Riggs wrote:
> I thought that might explain it, but then I'm surprised that it can still
> use an index when the first two columns of the index aren't in the query.
> Wouldn't that mean that it might have to walk the entire index to find
> matching rows?

> ....unless it's smart enough to realize that the first two columns will
> match everything. Which would be cool.

There's some limited smarts in there about deciding that leading columns
of an index don't matter to the sort ordering if they're constrained to
just one value by the query. But it doesn't catch the case you need,
which is that columns of an ORDER BY request are no-ops when they're
constrained to just one value.

That whole area has been rewritten for 8.3 and I believe it will handle
this case. No time to try it right now though.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Henrik 2007-10-04 21:15:47 Re: Query taking too long. Problem reading explain output.
Previous Message Richard Huxton 2007-10-04 21:01:45 Re: quickly getting the top N rows