diff --git a/doc/src/sgml/parallel.sgml b/doc/src/sgml/parallel.sgml
index d8f001d4b6..ee1023a98c 100644
--- a/doc/src/sgml/parallel.sgml
+++ b/doc/src/sgml/parallel.sgml
@@ -401,6 +401,55 @@ EXPLAIN SELECT * FROM pgbench_accounts WHERE filler LIKE '%x%';
+
+ Parallel Append
+
+
+ Whenever PostgreSQL needs to combine rows
+ from multiple sources into a single result set, it uses an
+ Append or MergeAppend plan node.
+ This commonly happens when implementing UNION ALL or
+ when scanning a partitioned table. Such nodes can be used in parallel
+ plans just as they can in any other plan. However, in a parallel plan,
+ it is also possible that the planner may choose to substitute a
+ Parallel Append node.
+
+
+
+ When an Append node is used in a parallel plan, each
+ process will execute the child plans in the order in which they appear,
+ so that all workers cooperate to execute the first child plan until it is
+ complete and then move to the second plan at around the same time.
+ When a Parallel Append is used instead, the executor
+ will instead spread out the workers as evenly as possible across its child
+ plans, so that multiple child plans are executed simultaneously. This
+ avoids contention between the workers, and also avoids paying the startup
+ cost of a child plan in those workers that never execute it.
+
+
+
+ Also, unlike a regular Append node, which can only have
+ partial children when used within a parallel plan, Parallel
+ Append node can have both partial and non-partial child plans.
+ Non-partial children will be scanned by only a single worker, since
+ scanning them more than once would preduce duplicate results. Plans that
+ involve appending multiple results sets can therefore achieve
+ coarse-grained parallelism even when efficient partial plans are not
+ available. For example, consider a query against a partitioned table
+ which can be only be implemented efficiently by using an index that does
+ not support parallel scans. The planner might choose a Parallel
+ Append of regular Index Scan plans; each
+ individual index scan would have to be executed to completion by a single
+ process, but different scans could be performed at the same time by
+ different processes.
+
+
+
+ can be used to disable
+ this feature.
+
+
+
Parallel Plan Tips