Re: MAX/MIN optimization via rewrite (plus query rewrites generally)

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
Дата
Msg-id 8198.1100186674@sss.pgh.pa.us
обсуждение исходный текст
Ответ на MAX/MIN optimization via rewrite (plus query rewrites generally)  (Mark Kirkwood <markir@coretech.co.nz>)
Ответы Re: MAX/MIN optimization via rewrite (plus query rewrites generally)  (Greg Stark <gsstark@mit.edu>)
Re: MAX/MIN optimization via rewrite (plus query rewrites generally)  (Bruno Wolff III <bruno@wolff.to>)
Список pgsql-hackers
"Zeugswetter Andreas DAZ SD" <ZeugswetterA@spardat.at> writes:
>> How are you planning to represent the association between MIN/MAX and
>> particular index orderings in the system catalogs?

> Don't we already have that info to decide whether an index handles 
> an "ORDER BY" without a sort node ?

We know how to determine that an index matches an ORDER BY clause.
But what has an aggregate called MAX() got to do with ORDER BY?  Magic
assumptions about operators named "<" are not acceptable answers; there
has to be a traceable connection in the catalogs.

As a real-world example of why I won't hold still for hard-wiring this:
a complex-number data type might have btree opclasses allowing it to be
sorted either by real part or by absolute value.  One might then define
max_real() and max_abs() aggregates on the type.  It should be possible
to optimize such aggregates the same way as any other max() aggregate.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: plperl Safe restrictions
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: ltree PostgreSQL Module