Re: The Future of Aggregation

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
> Kevin Grittner wrote:
>> David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> wrote:

>>> 5. Dependant Aggregates
>>>
>>> Item 5 makes items 1-4 a bit more complex as with this item
>>> there's opportunity for very good performance improvements by
>>> allowing aggregates like AVG(x) also perform all the required
>>> work to allow SUM(x) and COUNT(x) to be calculated for "free" in
>>> a query containing all 3 aggregates.
>>
>> Not only CPU is saved, but the optimizations for materialized
>> views would require the aggregate function's transition state to
>> be saved in each row, and the duplicate state information among
>> these functions would be a waste of space.
>
> Uh, this also requires serialization and deserialization of non-
> finalized transition state, no?

For that sort of optimization to incremental maintenance of
materialized views (when we get there), yes. That will be one of
many issues to sort out. Any reason you're focusing on that now?
Do you think we need to settle on a format for that to proceed with
the work David is discussing?

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company