@@ -393,6 +393,54 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
393393
394394 </sect2>
395395
396+ <sect2 id="parallel-append">
397+ <title>Parallel Append</title>
398+
399+ <para>
400+ Whenever <productname>PostgreSQL</productname> needs to combine rows
401+ from multiple sources into a single result set, it uses an
402+ <literal>Append</literal> or <literal>MergeAppend</literal> plan node.
403+ This commonly happens when implementing <literal>UNION ALL</literal> or
404+ when scanning a partitioned table. Such nodes can be used in parallel
405+ plans just as they can in any other plan. However, in a parallel plan,
406+ the planner may instead use a <literal>Parallel Append</literal> node.
407+ </para>
408+
409+ <para>
410+ When an <literal>Append</literal> node is used in a parallel plan, each
411+ process will execute the child plans in the order in which they appear,
412+ so that all participating processes cooperate to execute the first child
413+ plan until it is complete and then move to the second plan at around the
414+ same time. When a <literal>Parallel Append</literal> is used instead, the
415+ executor will instead spread out the participating processes as evenly as
416+ possible across its child plans, so that multiple child plans are executed
417+ simultaneously. This avoids contention, and also avoids paying the startup
418+ cost of a child plan in those processes that never execute it.
419+ </para>
420+
421+ <para>
422+ Also, unlike a regular <literal>Append</literal> node, which can only have
423+ partial children when used within a parallel plan, a <literal>Parallel
424+ Append</literal> node can have both partial and non-partial child plans.
425+ Non-partial children will be scanned by only a single process, since
426+ scanning them more than once would produce duplicate results. Plans that
427+ involve appending multiple results sets can therefore achieve
428+ coarse-grained parallelism even when efficient partial plans are not
429+ available. For example, consider a query against a partitioned table
430+ which can be only be implemented efficiently by using an index that does
431+ not support parallel scans. The planner might choose a <literal>Parallel
432+ Append</literal> of regular <literal>Index Scan</literal> plans; each
433+ individual index scan would have to be executed to completion by a single
434+ process, but different scans could be performed at the same time by
435+ different processes.
436+ </para>
437+
438+ <para>
439+ <xref linkend="guc-enable-parallel-append" /> can be used to disable
440+ this feature.
441+ </para>
442+ </sect2>
443+
396444 <sect2 id="parallel-plan-tips">
397445 <title>Parallel Plan Tips</title>
398446