Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commite80f2b3

Browse files
committed
Update parallel.sgml for Parallel Append
Patch by me, reviewed by Thomas Munro, in response to a complaintfrom Adrien Nayrat.Discussion:http://postgr.es/m/baa0d036-7349-f722-ef88-2d8bb3413045@anayrat.info
1 parent0d5f05c commite80f2b3

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)

[8]ページ先頭

©2009-2025 Movatter.jp