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