Re: Combining Aggregates - Mailing list pgsql-hackers

From David Rowley
Subject Re: Combining Aggregates
Date
Msg-id CAKJS1f91r0aDstUgSp6k0C4e3BpvfB3mhBTpUAzFACsHEH_h1w@mail.gmail.com
Whole thread Raw
In response to Re: Combining Aggregates  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Combining Aggregates  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 20 January 2016 at 05:58, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 21, 2015 at 4:02 AM, David Rowley
> <david.rowley@2ndquadrant.com> wrote:
>> Now, there has been talk of this previously, on various threads, but I don't
>> believe any final decisions were made on how exactly it should be done. At
>> the moment I plan to make changes as follows:

Oh, one more point: is there any reason why all of this needs to be a
single (giant) patch?  I feel like the handling of internal states
could be a separate patch from the basic patch to allow partial
aggregation and aggregate-combining, and that the latter could be
committed first if we had a reasonably final version of it.  That
seems like it would be easier from a review standpoint, and might
allow more development to proceed in parallel, too.

I didn't ever really imagine that I'd include any actual new combinefns or serialfn/deserialfn in this patch. One set has of course now ended up in there, I can move these off to the test patch for now. 

Did you imagine that the first patch in the series would only add the aggcombinefn column to pg_aggregate and leave the aggserialfn stuff until later? I thought it seemed better to get the infrastructure committed in one hit, then add a bunch of new combinefn, serialfn, deserialfns for existing aggregates in follow-on commits. 

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

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: PATCH: postpone building buckets to the end of Hash (in HashJoin)
Next
From: Peter Geoghegan
Date:
Subject: Re: PATCH: Extending the HyperLogLog API a bit