A parallel-query toggle, and one of the more interesting members of the enable_* family to flip, because what it switches off has a clean, predictable replacement. Default on, context user, same family caveat as enable_async_append: a diagnostic instrument, not a tuning knob.
Gather, and the problem Gather Merge solves
When PostgreSQL runs part of a query in parallel, the results from the worker processes have to be funneled back to the leader, and there are two nodes that do that funneling. The plain Gather node collects tuples from the workers in whatever order they happen to arrive — fast, simple, and it makes no promises about ordering. The docs are blunt about the consequence: Gather reads from the workers “in whatever order is convenient, destroying any sort order that may have existed.”
That destruction is a problem when the query wants its rows ordered — an ORDER BY, or any operation upstream that needs sorted input. Before Gather Merge existed, a parallel plan that needed ordered output had to collect everything with Gather and then sort the combined stream on the leader: Sort → Gather → Parallel Seq Scan. The leader did all the sorting work serially, which throttled exactly the parallelism you were trying to exploit.
Gather Merge, added in PostgreSQL 10, fixes that by pushing the sort down into the workers. Each worker sorts its own chunk in parallel, and the leader does only an order-preserving merge of the already-sorted streams — the same cheap k-way merge that powers a merge join’s final step. In EXPLAIN the shape becomes Gather Merge → Sort → Parallel Seq Scan, with the Sort now below the gather, running in every worker at once instead of once on the leader. When you see Gather Merge at the top of a parallel subtree, the docs tell you exactly what it means: every worker is producing sorted tuples and the leader is merging them. This is what makes parallel ORDER BY, parallel merge-join inputs, and the partial-then-finalize aggregation paths actually parallel rather than parallel-until-the-sort.
Symptoms that warrant flipping it
The diagnostic value here is unusually clean, because disabling Gather Merge produces a specific, known alternative: the planner falls back to the old Sort → Gather arrangement, doing the sort on the leader. That makes this a good controlled experiment.
Reach for SET enable_gathermerge = off when a parallel query with ordered output is underperforming and you want to know whether the merge-on-leader step is the bottleneck. Two distinct pathologies tend to send people here. The first is a Gather Merge that should be fast but isn’t, where the EXPLAIN ANALYZE shows the workers’ Sort nodes spilling — Sort Method: external merge Disk: instead of an in-memory quicksort — which means each worker is starved of work_mem and the parallel sort is thrashing to disk in every worker at once. There the real lever is work_mem (remember it’s per-worker, so a parallel Gather Merge with four workers can multiply your memory footprint), and flipping enable_gathermerge off merely tells you whether the alternative serial sort is, perversely, faster on your data — useful information, not a fix. The second is the opposite: a Gather Merge chosen on a small result set where the parallel-worker startup overhead wasn’t worth it, usually a sign of a row misestimate. There, EXPLAIN ANALYZE showing actual rows far below what the plan expected points at stale statistics, and the cure is ANALYZE, not the GUC.
In both cases the procedure is the family’s standard one: set it off for the session, re-run EXPLAIN (ANALYZE), and compare the Sort → Gather fallback against the Gather Merge plan to learn which is faster and, more importantly, why the planner chose as it did. Then go fix the cause — work_mem, statistics, or sometimes parallel_setup_cost if the planner is reaching for parallelism on queries too small to deserve it. Leaving enable_gathermerge = off in postgresql.conf is the usual family mistake: it doesn’t make your sorts cheaper, it just forbids the planner from parallelizing them and quietly forces every ordered parallel query back onto a single-threaded leader sort. Diagnose with it, then set it back, and spend your effort on the parameter the probe actually pointed at.