| 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: | Whole Thread | Raw Message | 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 |