On Sat, Dec 19, 2015 at 5:39 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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].
Thanks for the details.
Generated partial aggregate plan on top of partial path list that is available.
The code changes are took from the parallel join patch for reference.
Instead of generating parallel aggregate plan on top of partial path list
if exists, how about checking the cost of normal aggregate and parallel
aggregate and decide which one best?
The parallel aggregate patch is now separated from combine aggregate patch.
The latest combine aggregate patch is also attached in the mail for reference
as parallel aggregate patch depends on it.
Attached latest performance report. Parallel aggregate is having some overhead
in case of low selectivity.This can be avoided with the help of cost comparison
between normal and parallel aggregates.
Regards,
Hari Babu
Fujitsu Australia