Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

Re: [HACKERS] Small improvement to parallel query docs

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

[HACKERS] Small improvement to parallel query docs

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