On 17 December 2014 at 10:02, Atri Sharma <atri.jiit@gmail.com> wrote:
>
>
> On Wed, Dec 17, 2014 at 3:23 PM, Simon Riggs <simon@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
portionof 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
