Parameter · Query Tuning / Planner Method Configuration
enable_parallel_append
Enables the planner's use of parallel append plans.
- Default:
on - Type: bool
- Applies: Session (any user)
In plain words
When a query reads many partitions (or UNION ALL branches), Parallel Append lets workers pick different partitions to work on at the same time, instead of all workers marching through the partitions one by one. Turn it off to compare.
For DBAs and operators
A plain Append under Gather runs its children in order, and every worker cooperates on the same child (each child must then be a parallel-aware scan). A Parallel Append hands out children to workers: a worker that finishes one child picks the next unclaimed one, starting with the most expensive. It can also mix parallel-aware children with non-parallel ones, which a plain Append cannot.
Measured on 18.6, counting rows in a table with four range partitions: Gather (2 workers) → Parallel Append, cost 6,768. With enable_parallel_append = off: Gather (1 worker planned) → Append of four Parallel Seq Scans, cost 7,283. The difference is modest here; it grows with many partitions of uneven size, or children that cannot be parallel scans (for example foreign tables).
The number of workers for a Parallel Append is based on the number of children and the largest child's worker count, capped by max_parallel_workers_per_gather.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
enable_partition_pruning enable_async_append max_parallel_workers_per_gather enable_parallel_hash