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=fvrrudctf...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
