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