Re: The Future of Aggregation - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: The Future of Aggregation
Date
Msg-id 55770405.5030608@2ndquadrant.com
Whole thread Raw
In response to Re: The Future of Aggregation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: The Future of Aggregation  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers

On 06/09/15 16:10, Tomas Vondra wrote:
> Hi,
>
> On 06/09/15 12:58, David Rowley wrote:
>>
...
>> Items 1-4 above I believe require support of "Aggregate State
>> Combine Support" -> https://commitfest.postgresql.org/5/131/ which I
>> believe will need to be modified to implement complex database types
>> to backup our internal aggregate state types so that these types be
>> properly passed between executor nodes, between worker processes and
>> perhaps foreign data wrappers (maybe just postgres_fdw I've not
>> looked into this yet)
>
> I think yet another use case that might benefit from this would be
> 'memory-bounded hash aggregate'. Jeff Davis was working on a different
> approach that worked quite well for fixed-length states, but for
> handling custom states in 'internal' data type, the (de)serialization
> seems like a must for this use case.

... and yet another use case for 'aggregate state combine' that I just 
remembered about is grouping sets. What GROUPING SET (ROLLUP, ...) do 
currently is repeatedly sorting the input, once for each grouping. What 
could happen in some cases is building the most detailed aggregation 
first, then repeatedly combine these partial states.

regards

--
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: The Future of Aggregation
Next
From: Tom Lane
Date:
Subject: "could not adopt C locale" failure at startup on Windows