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
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 |