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