Parameter · Query Tuning / Planner Method Configuration
enable_gathermerge
Enables the planner's use of gather merge plans.
- Default:
on - Type: bool
- Applies: Session (any user)
In plain words
When parallel workers each sort their share of the rows, a Gather Merge node merges those sorted streams into one sorted result, like merging sorted piles of cards. Without it the planner must either sort after gathering or skip parallelism.
For DBAs and operators
Gather returns worker rows in whatever order they arrive; Gather Merge keeps the order by doing a k-way merge (a binary heap over the leader and the workers). It is what lets ORDER BY … LIMIT, sorted aggregation and merge joins use parallel sorts.
On the test table, SELECT * FROM t ORDER BY pad LIMIT 1000 planned Limit → Gather Merge → Sort → Parallel Seq Scan at cost 11,014. With enable_gathermerge = off it fell back to a serial Sort → Seq Scan at 15,241.
Gather Merge has its own costs: the leader must wait until every worker has produced its first row before it can return anything, and the merge adds CPU per row (charged through cpu_operator_cost and parallel_tuple_cost). With very uneven workers a plain Gather plus a final Sort can be faster; this switch is the quick way to test that. EXPLAIN ANALYZE shows Workers Planned versus Workers Launched: if workers are not launched the leader does all the work.
How to change it
Any user can change it for their session with SET.
See it in context
Related parameters
max_parallel_workers_per_gather parallel_tuple_cost enable_sort parallel_leader_participation