Re: MAX/MIN optimization via rewrite (plus query rewrites generally)

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 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 01:21:31
Message-ID: 20041111012131.GF15213@surnet.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

There could be multiple calls to that function along the query's way to
executor, each one at a different point (with a parameter specifying
which one it is), that would try to rewrite the query optimizing the
aggregate. So we could optimize some aggregates at one point, and
others at a different point, whichever makes the most sense.

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Hay dos momentos en la vida de un hombre en los que no debería
especular: cuando puede permitírselo y cuando no puede" (Mark Twain)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2004-11-11 01:29:07 Re: Reorganization of the translation files
Previous Message Ramy M. Hassan 2004-11-11 00:44:08 Re: sp-gist porting to postgreSQL