Re: Aggregate Supporting Functions

On 10 June 2015 at 02:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Kevin Grittner <kgrittn(at)ymail(dot)com> writes:
> > David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> >> [ avoid duplicate calculations for related aggregates ]
>
> > From the information you have proposed storing, with cost factors
> > associated with the functions, it seems technically possible to
> > infer that you could run (for example) the avg() aggregate to
> > accumulate both but only run the final functions of the aggregates
> > referenced by the query. That seems like an optimization to try
> > hard to forget about until you have at least one real-world use
> > case where it would yield a significant benefit. It seems
> > premature to optimize for that before having the rest working.
>
> Actually, I would suggest that you forget about all the other aspects
> and *just* do that, because it could be made to work today on existing
> aggregate functions, and it would not require hundreds-to-thousands
> of lines of boilerplate support code in the grammar, catalog support,
> pg_dump, yadda yadda. That is, look to see which aggregates use the
> same transition function and run that just once. We already have the
> rule that the final function can't destroy the transition output,
> so running two different final functions on the same transition result
> should Just Work.
>
>
Good idea.
I believe the only extra check, besides do they use the same transfn, would
be the initvalue of the aggregate.

I'll write a patch and post in the next couple of days.

Regards

David Rowley

--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services