Re: Small improvement to parallel query docs

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Brad DeJong <Brad(dot)Dejong(at)infor(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Small improvement to parallel query docs
Date: 2017-02-14 08:25:14
Message-ID: CAA4eK1K3MY5CQcHRYCYNFiXFqo3C82N1Mm_Pz2D67Fo6H7ZgGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 14, 2017 at 3:33 AM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 14 February 2017 at 10:56, Brad DeJong <Brad(dot)Dejong(at)infor(dot)com> wrote:
>> David Rowley wrote:
>>> I propose we just remove the whole paragraph, and mention about
>>> the planning and estimated number of groups stuff in another new paragraph.
>>>
>>> I've attached a patch to this effect ...
>>
>> s/In a worse case scenario/In the worst case scenario,/
>>
>> Other than that, the phrasing in the new patch reads very smoothly.
>
> Thanks. Updated patch attached.
>
>

+ Aggregate</> stage. For such cases there is clearly going to be no
+ performance benefit to using parallel aggregation.

A comma is required after "For such cases"

> The query planner takes
> + this into account during the planning process and will choose how to
> + perform the aggregation accordingly.

This part of the sentence sounds unclear. It doesn't clearly
indicate that planner won't choose a parallel plan in such cases.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2017-02-14 09:01:47 Re: possibility to specify template database for pg_regress
Previous Message Fabien COELHO 2017-02-14 07:45:01 Re: pg_waldump's inclusion of backend headers is a mess