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)
Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Список | 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 по дате отправления: