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

From Kevin Grittner
Subject Re: The Future of Aggregation
Date
Msg-id 958724031.7990098.1433862966636.JavaMail.yahoo@mail.yahoo.com
Whole thread Raw
In response to Re: The Future of Aggregation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: The Future of Aggregation  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> Kevin Grittner wrote:
>> David Rowley <david.rowley@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Map basebackup tablespaces using a tablespace_map file
Next
From: Tomas Vondra
Date:
Subject: Re: The Future of Aggregation