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)
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 |