Re: Evaluation of secondary sort key.

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