Re: Any better plan for this query?..

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Dimitri <dimitrik(dot)fr(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Merlin Moncure <mmoncure(at)gmail(dot)com>, PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Any better plan for this query?..
Date: 2009-05-19 11:17:47
Message-ID: alpine.DEB.2.00.0905191159530.2341@aragorn.flymine.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, 19 May 2009, Simon Riggs wrote:
> Both plans for this query show an IndexScan on a two column-index, with
> an Index Condition of equality on the leading column. The ORDER BY
> specifies a sort by the second index column, so the top-level Sort is
> superfluous in this case.
>
> My understanding is that we don't currently eliminate superfluous
> additional sorts of this kind. Now I know that is a hard subject, but it
> seems straightforward to consider interesting sort order equivalence
> when we have constant equality constraints.

Yes, Postgres has been missing the boat on this one for a while. +1 on
requesting this feature.

Speaking of avoiding large sorts, I'd like to push again for partial
sorts. This is the situation where an index provides data sorted by column
"a", and the query requests data sorted by "a, b". Currently, Postgres
sorts the entire data set, whereas it need only group each set of
identical "a" and sort each by "b".

Matthew

--
Riker: Our memory pathways have become accustomed to your sensory input.
Data: I understand - I'm fond of you too, Commander. And you too Counsellor

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Simon Riggs 2009-05-19 11:36:25 Re: Any better plan for this query?..
Previous Message Simon Riggs 2009-05-19 10:57:26 Re: Any better plan for this query?..