Re: Aggregate Supporting Functions - Mailing list pgsql-hackers

From David Rowley
Subject Re: Aggregate Supporting Functions
Date
Msg-id CAKJS1f_vUfC+aWPFV1BkfCZMa39A7eWaFn9DCcyc+tgtC+qndw@mail.gmail.com
Whole thread Raw
In response to Re: Aggregate Supporting Functions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On 10 June 2015 at 02:26, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Kevin Grittner <kgrittn@ymail.com> writes:
> David Rowley <david.rowley@2ndquadrant.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/
 PostgreSQL Development, 24x7 Support, Training & Services

pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: pg_rewind failure by file deletion in source server
Next
From: Taiki Kondo
Date:
Subject: [Proposal] Progress bar for pg_dump/pg_restore