From: | Bruno Wolff III <bruno(at)wolff(dot)to> |
---|---|
To: | Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Kirkwood <markir(at)coretech(dot)co(dot)nz>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: MAX/MIN optimization via rewrite (plus query rewrites generally) |
Date: | 2004-11-11 02:40:26 |
Message-ID: | 20041111024026.GA32738@wolff.to |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Nov 10, 2004 at 22:21:31 -0300,
Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksander Kmetec | 2004-11-11 02:51:24 | Re: Reorganization of the translation files |
Previous Message | Mark Kirkwood | 2004-11-11 02:27:18 | Re: MAX/MIN optimization via rewrite (plus query rewrites |