From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: The Future of Aggregation |
Date: | 2015-06-09 15:19:33 |
Message-ID: | 55770405.5030608@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-06-09 15:20:06 | "could not adopt C locale" failure at startup on Windows |
Previous Message | Kevin Grittner | 2015-06-09 15:16:06 | Re: The Future of Aggregation |