Re: Parallel Aggregate

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, 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: 2016-03-16 21:08:10
Message-ID: CAKJS1f_vWkfDcKaLuWMpUxk1dXEXQNSO0q1Yv_S8QNSB5yhJmw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 March 2016 at 01:29, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 16, 2016 at 8:19 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> Isn't it better to call it as Parallel Aggregate instead of Partial
>> Aggregate. Initialy, we have kept Partial for seqscan, but later on we
>> changed to Parallel Seq Scan, so I am not able to think why it is better to
>> call Partial incase of Aggregates.
>
> I think partial is the right terminology. Unlike a parallel
> sequential scan, a partial aggregate isn't parallel-aware and could be
> used in contexts having nothing to do with parallelism. It's just
> that it outputs transition values instead of a finalized value.

+1 the reason the partial aggregate patches have been kept separate
from the parallel aggregate patches is that partial aggregate will
serve for many other purposes. Parallel Aggregate is just one of many
possible use cases for this, so it makes little sense to give it a
name according to a single use case.

--
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 Vitaly Burovoy 2016-03-16 21:27:46 Re: [PATCH] Integer overflow in timestamp[tz]_part() and date/time boundaries check
Previous Message David Rowley 2016-03-16 21:05:57 Re: Parallel Aggregate