Re: Parallel Aggregate

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>, Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel Aggregate
Date: 2015-12-18 18:39:01
Message-ID: CA+TgmoaUwT4JdBPwfSiWQwdONsDyGOgFJD7mmz-uAJ-i6feQtA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 16, 2015 at 5:59 AM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-12-18 18:50:34 Re: A Typo in regress/sql/privileges.sql
Previous Message Robert Haas 2015-12-18 18:32:23 Re: extend pgbench expressions with functions