Re: MAX/MIN optimization via rewrite (plus query rewrites generally) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: MAX/MIN optimization via rewrite (plus query rewrites generally)
Date
Msg-id 20041111173858.GA4904@surnet.cl
Whole thread Raw
In response to Re: MAX/MIN optimization via rewrite (plus query rewrites generally)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: MAX/MIN optimization via rewrite (plus query rewrites generally)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Nov 11, 2004 at 01:08:39AM -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > 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 can't get very excited about this, because how would you make a
> reasonably stable/narrow API for such a thing?  The function as you
> propose it would have to know everything about not only the planner's
> data representations but the N specific places it would be called from.

No, the function would discard all calls except the one it knows how
to optimize.  The point in having multiple call places is that some
aggregates will likely be optimized in some place, and others somewhere
else.  Most likely, a first patch would include only the call site that
would help in optimizing min() and max().

Of course, an aggregate could specify no optimizing function, which
would be the current situation, where no aggregate knows how to optimize
itself.

Re: knowing internal representation, I think this is required anyway;
else the optimization would only work on a very limited numer of
situations.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"A wizard is never late, Frodo Baggins, nor is he early.
He arrives precisely when he means to."  (Gandalf, en LoTR FoTR)



pgsql-hackers by date:

Previous
From: "Gevik Babakhani"
Date:
Subject: newbie compile question. please help
Next
From: Bruno Wolff III
Date:
Subject: Re: MAX/MIN optimization via rewrite (plus query rewrites