Re: Parallel Aggregate - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel Aggregate
Date
Msg-id CA+TgmoaUwT4JdBPwfSiWQwdONsDyGOgFJD7mmz-uAJ-i6feQtA@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Aggregate  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Parallel Aggregate  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
On Wed, Dec 16, 2015 at 5:59 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> One thing I noticed is that you're only enabling Parallel aggregation when
> there's already a Gather node in the plan. Perhaps this is fine for a proof
> of concept, but I'm wondering how we can move forward from this to something
> that can be committed.

As far as that goes, I think the infrastructure introduced by the
parallel join patch will be quite helpful here.  That introduces the
concept of a "partial path" - that is, a path that needs a Gather node
in order to be completed.  And that's exactly what you need here:
after join planning, if there's a partial path available for the final
rel, then you can consider
FinalizeAggregate->Gather->PartialAggregate->[the best partial path].
Of course, whether a partial path is available or not, you can
consider Aggregate->[the best regular old path].

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: extend pgbench expressions with functions
Next
From: Tom Lane
Date:
Subject: Re: Patch: ResourceOwner optimization for tables with many partitions