8000 Update parallel.sgml for Parallel Append · postgres/postgres@e80f2b3 · GitHub
[go: up one dir, main page]
Skip to content

Commit e80f2b3

Browse files
robertmhaasrobertmhaas
committed
Update parallel.sgml for Parallel Append
Patch by me, reviewed by Thomas Munro, in response to a complaint from Adrien Nayrat. Discussion: http://postgr.es/m/baa0d036-7349-f722-ef88-2d8bb3413045@anayrat.info
1 parent 0d5f05c commit e80f2b3

File tree

1 file changed

+48
-0
lines changed

1 file changed

+48
-0
lines changed

‎doc/src/sgml/parallel.sgml

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -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

0 commit comments

Comments
 (0)
0