Re: Parallel Aggregate

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(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-21 07:48:14
Message-ID: CAKJS1f8272VRL_JcSXmFxFp8PyV_O3b_O4O0M=eSSYhbU2aHLQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 21 December 2015 at 17:23, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

>
> 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.
>
>
Hi, Thanks for posting an updated patch.

Would you be able to supply a bit more detail on your benchmark? I'm
surprised by the slowdown reported with the high selectivity version. It
gives me the impression that the benchmark might be producing lots of
groups which need to be pushed through the tuple queue to the main process.
I think it would be more interesting to see benchmarks with varying number
of groups, rather than scan selectivity. Selectivity was important for
parallel seqscan, but less so for this, as it's aggregated groups we're
sending to main process, not individual tuples.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2015-12-21 07:48:52 Re: Threads in PostgreSQL
Previous Message Michael Paquier 2015-12-21 07:45:21 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.