Re: Small improvement to parallel query docs

On 14 February 2017 at 10:10, Brad DeJong <Brad(dot)Dejong(at)infor(dot)com> wrote:
> Robert Haas wrote:
>
>> + <literal>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 <literal>GROUP BY</> clause,
>> + separate subtotals must be computed for each group seen by each parallel
>> + worker. Each of these subtotals must then be combined into an overall
>> + total for each group once the parallel aggregate portion of the plan is
>> + complete. This means that queries which produce a low number of groups
>> + relative to the number of input rows are often far more attractive to the
>> + query planner, whereas queries which don't collect many rows into each
>> + group are less attractive, due to the overhead of having to combine the
>> + subtotals into totals, of which cannot run in parallel.
>
>> I don't think "of which cannot run in parallel" is good grammar. I'm somewhat unsure whether the rest is an improvement or not. Other opinions?
>
> Does this read any more clearly?
>
> + <literal>COUNT(*)</>, each worker must compute subtotals which are later
> + combined in order to produce an overall total for the final answer. If
> + the query involves a <literal>GROUP BY</> clause, separate subtotals
> + must be computed for each group seen by each parallel worker. After the
> + parallel aggregate portion of the plan is complete, there is a serial step
> + where the group subtotals from all of the parallel workers are combined
> + into an overall total for each group. Because of the overhead of combining
> + the subtotals into totals, plans which produce few groups relative to the
> + number of input rows are often more attractive to the query planner
> + than plans which produce many groups relative to the number of input rows.

Actually looking over this again I think it's getting into too much
detail which is already described in the next paragraph (of which I
think is very clear). 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, which also just removes the text
about why we don't support Merge Join. I felt something needed written
in its place, so I mentioned that identical hash tables are created in
each worker. This is perhaps not required, but the paragraph seemed a
bit empty without it. I also noticed a mistake "based on a column
taken from the inner table", this "inner" I assume should be "outer"
since it surely must be talking of a parameterised index scan?, in
which case the parameter is from the outer side, not the inner.

--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services