Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
| От | Bruno Wolff III |
|---|---|
| Тема | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
| Дата | |
| Msg-id | 20041111024026.GA32738@wolff.to обсуждение исходный текст |
| Ответ на | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) (Alvaro Herrera <alvherre@dcc.uchile.cl>) |
| Список | pgsql-hackers |
On Wed, Nov 10, 2004 at 22:21:31 -0300, Alvaro Herrera <alvherre@dcc.uchile.cl> wrote: > On Wed, Nov 10, 2004 at 07:18:59PM -0500, Tom Lane wrote: > > > A more radical way of handling it would be to detect the relevance of an > > indexscan in indxpath.c and generate a special kind of Path node; this > > would not generalize to other sorts of things as you were hoping, but > > I'm unconvinced that the mechanism is going to be very general-purpose > > anyway. The major advantage is that this would work conveniently for > > comparing the cost of a rewritten query to a non-rewritten one. > > What about having a new column in pg_aggregate which would point to a > function that would try to optimize the aggregate's handling? I think you want to store an operator class and a direction. This allows you to figure out what indexes might be usable. This could be used on all of the max and min aggregates and the boolean and and or aggregates.
В списке pgsql-hackers по дате отправления: