Re: Evaluation of secondary sort key.

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: David Fetter <david(at)fetter(dot)org>
Cc: Jesper Krogh <jesper(at)krogh(dot)cc>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Evaluation of secondary sort key.
Date: 2011-04-09 16:23:09
Message-ID: 20110409162309.GB26437@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, Apr 09, 2011 at 09:17:10AM -0700, David Fetter wrote:

> > 2011-04-09 15:18:22.138 testdb=# select id from test1 where id < 3
> > order by id,testsort(id);
> > id
> > ----
> > 1
> > 2
> > (2 rows)
> >
> > Time: 3001.896 ms
> >
> > It seems strange that there is a need to evaluate testsort(id) at
> > all in this case.
>
> How would PostgreSQL know that sorting by id leaves no ambiguity for
> the next key to address?

Well, it doesn't know that, but I guess the point is it could wait with
evaluating the second key until it needs it.

The reason ot works as it does now is that the ORDER BY fields are
added as hidden fields to the query, like:

select id, /*hidden*/ id, /*hidden*/ testsort(id) from test1 where id < 3 order by 2, 3;

Here it's obvious why the evaluation happens. To avoid this evaluation
would require redoing the way sorts work (I think).

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> Patriotism is when love of your own people comes first; nationalism,
> when hate for people other than your own comes first.
> - Charles de Gaulle

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Krogh 2011-04-09 16:23:25 Re: Evaluation of secondary sort key.
Previous Message David Fetter 2011-04-09 16:17:10 Re: Evaluation of secondary sort key.