On 15 February 2017 at 03:41, Robert Haas wrote:
> On Tue, Feb 14, 2017 at 5:17 AM, David Rowley
> wrote:
>> Updated patch attached.
>
> Committed and back-patched to 9.6.
Great. Thanks Robert.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
On Tue, Feb 14, 2017 at 5:17 AM, David Rowley
wrote:
> On 14 February 2017 at 21:25, Amit Kapila wrote:
>> +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"
>
> Added
>
>
On 14 February 2017 at 21:25, Amit Kapila wrote:
> +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"
Added
>> The query planner takes
>> +this into account during the p
On Tue, Feb 14, 2017 at 3:33 AM, David Rowley
wrote:
> On 14 February 2017 at 10:56, Brad DeJong 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
On 14 February 2017 at 10:56, Brad DeJong 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
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 i
On 14 February 2017 at 10:10, Brad DeJong wrote:
> Robert Haas wrote:
>
>> +COUNT(*), each worker must compute subtotals which later
>> must
>> +be combined to produce an overall total in order to produce the final
>> +answer. If the query involves a GROUP BY clause,
>> +separate
Robert Haas wrote:
> +COUNT(*), each worker must compute subtotals which later must
> +be combined to produce an overall total in order to produce the final
> +answer. If the query involves a GROUP BY clause,
> +separate subtotals must be computed for each group seen by each paral
On Mon, Feb 13, 2017 at 3:29 PM, David Rowley
wrote:
> On 14 February 2017 at 09:21, Robert Haas wrote:
>> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
>> -table. Each worker will execute the outer side of the plan in full,
>> which
>> -is why merge joins are not supported here. The out
On 14 February 2017 at 09:21, Robert Haas wrote:
> On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
> -table. Each worker will execute the outer side of the plan in full, which
> -is why merge joins are not supported here. The outer side of a merge join
> -will often involve sorting the e
On Sun, Feb 12, 2017 at 7:16 PM, David Rowley
wrote:
> Tomas Vondra pointed out to me that there's an error in parallel.sgml
> which confuses the inner and outer sides of the join.
>
> I've attached a patch which fixes this, although I think I'm still
> missing the point to text's explanation of w
Tomas Vondra pointed out to me that there's an error in parallel.sgml
which confuses the inner and outer sides of the join.
I've attached a patch which fixes this, although I think I'm still
missing the point to text's explanation of why Merge Join is not
included due to it having to sort the inne
12 matches
Mail list logo
