Martijn van Oosterhout <klep...@svana.org> writes:
> On Sat, Apr 09, 2011 at 09:17:10AM -0700, David Fetter wrote:
>>> 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.
I think that would be a positive disimprovement. The current design
guarantees that volatile sort expressions are evaluated exactly once,
in the order the rows are read from the data source. There would be no
guarantees at all, either as to the number of evaluations or the order
in which they happen, if we tried to do evaluation only during the
actual sort.
Another small problem is that any such thing would require carrying
along some kind of closure (ie, the expression and all its input
values), not just the final sort key value, in tuples being sorted.
The ensuing complexity, speed penalty, and increase in data volume
to be sorted would be paid by everybody, making this probably a net
performance loss when considered across all applications.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
