Append

An Append node runs its child plans and concatenates their rows. It's how UNION ALL and scans across a partitioned table's children are assembled. A parallel-aware variant divides children among workers.

For UNION ALL, and for queries over partitioned tables / inheritance hierarchies after pruning.

Healthy. The thing to check on partitioned tables is pruning: if one child dominates the runtime, the planner may be scanning partitions it could have excluded.

Where it shows up

Append is the plan-level "concatenate." You see it for UNION ALL, for scans across a partitioned table after pruning, and for scans across an inheritance hierarchy. It runs each child plan in turn and emits all of its rows before moving to the next.

Partition pruning is the thing to check

For a partitioned table, the planner ideally proves at planning time which partitions can satisfy the query and only emits those as Append children. Sometimes a condition is too complex for static pruning but can still be pruned at runtime, in which case you'll see fewer children actually scanned than originally planned — look for Subplans Removed: N.

If one child dominates the runtime (the analyzer flags this with an "Append child takes …% of the parent's time" finding), the planner usually scanned a partition it didn't need to. Make sure the WHERE clause expressions are directly comparable to the partition key — wrapping the key in a function defeats pruning.

Parallel Append

When the planner builds a parallel plan over an Append, it may use a Parallel Append: workers divide the children among themselves so multiple partitions can be scanned simultaneously. That can help a lot for partitioned analytical queries — the catch is each child still bounds its own parallelism, so total worker use stays under max_parallel_workers.

Append vs Merge Append

Append doesn't preserve order. If you need rows in a global order across the children (an ORDER BY over a partitioned table whose children supply order via their own indexes), the planner picks Merge Append instead — it merges the pre-sorted child streams without a final big Sort.

• Append child imbalance — one branch dominates, hinting at missed partition pruning

Paste a plan into the analyzer →

enable_partition_pruningmax_parallel_workers_per_gather

How we tune these →

• Merge Append
• Recursive Union
• Gather