Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
В списке pgsql-hackers по дате отправления:
| От | Bruno Wolff III |
|---|---|
| Тема | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
| Дата | |
| Msg-id | 20041111180320.GD25936@wolff.to обсуждение исходный текст |
| Ответ на | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
On Thu, Nov 11, 2004 at 10:24:34 -0500, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > 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. Wouldn't knowing an opclass and direction associated with an aggregrate function allow you to do this?
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера