On 17 December 2014 at 10:02, Atri Sharma <atri.j...@gmail.com> wrote:
>
>
> On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>>
>> KaiGai, David Rowley and myself have all made mention of various ways
>> we could optimize aggregates.
>>
>> Following WIP patch adds an extra function called a "combining
>> function", that is intended to allow the user to specify a
>> semantically correct way of breaking down an aggregate into multiple
>> steps.
>>
>> Gents, is this what you were thinking? If not...
>>
>>
>
> A quick look at the patch makes me assume that the patch does not handle the
> problem of combining transvals or move at all in that direction (which is
> fine, just reconfirming).
There are no applications of the new function at present. Each would
be similar, but unsure as to whether they would be identical.
> So, essentially, we are adding a "grand total" on top of individual sum() or
> count() operations,right?
The idea is to be able to do aggregation in multiple parts. For
example, allowing parallel query to have a plan like this
Aggregate
->Gather (subPlan is repeated N times on each parallel worker)
->Aggregate
-->ParallelSeqScan (scans a distinct portion of a table)
or to allow a serial plan where an aggregate was pushed down below a
join, like this
CURRENT PLAN
Aggregate
-> Join
-> Scan BaseTable1
-> Scan BaseTable2
PRE-AGGREGATED PLAN
Aggregate
-> Join
-> PreAggregate (doesn't call finalfn)
-> Scan BaseTable1
-> Scan BaseTable2
and also allow the above plan to be replaced by a Matview plan like this
Aggregate
-> Join
-> Scan BaseTable1.matviewA
-> Scan BaseTable2
where we would assume that the contents of matviewA are
pre-aggregations that could be further combined.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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
