Hi,
On 06/09/15 12:58, David Rowley wrote:
>
> These are things along the lines of:
>
> 1. Parallel Aggregation (computes each aggregate state in parallel
> worker processes and then merges these states in serial mode)
> 2. Aggregate push-down / Aggregate before join (requires passing
> partially computed aggregate states between executor nodes)
> 3. Auto-updating Materialized views (ones which contain aggregate functions)
> 4. Foreign table aggregation
> 5. Dependant Aggregates (I talked about earlier here ->
> http://www.postgresql.org/message-id/CAKJS1f8ebkc=EhEq+ArM8vwYZ5vSapJ1Seub5=FvRRuDCtFfsQ@mail.gmail.com)
>
> 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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
