parallel_leader_participation

parallel_leader_participation — Controls whether Gather and Gather Merge also run subplans. Observed in PG11–19 Beta 3; its last measured boot default is on in PG19 Beta 3, with user context. This is a beta-snapshot fact and can change before PostgreSQL 19 GA.

Note

Fact — official short description: “Controls whether Gather and Gather Merge also run subplans.”

Identity

Type , Valuebool: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value—: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueResource Usage / Worker Processes: Upstream classification
Latest boot value , Valueon: on

Lifecycle

Fact	Value
First observed	PG11
Present in	PG11–19 Beta 3
Removed in	No
Introduction commit	`e5253fdc4f5f` — Add parallel_leader_participation GUC.
Commit date	2017-11-15
Discussion	thread 1

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG11–19 Beta 3	`on`	—	on

How it works

parallel_leader_participation controls whether the process above Gather or Gather Merge also runs the parallel subplan while coordinating workers. With it off, the leader focuses on reading worker output.

Leader participation can add useful CPU when result production is expensive, but a leader busy executing the subplan may be slower to consume a large worker result stream.

The value is a planning/execution policy for eligible parallel plans, not an extra worker slot. Its effect depends on tuple volume, Gather versus Gather Merge, worker availability, and where the bottleneck lies. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

Tip

Advice. These are workload-specific starting points and must be validated with measurements.

Workload	Guidance
OLTP	Keep the default on unless a representative Gather plan shows that the leader is too busy executing the subplan to consume worker tuples promptly. Test off only at session scope and compare first-row latency, total latency, and worker blocking.
OLAP	For CPU-heavy subplans, leader participation often adds useful execution capacity; for very large result streams, disabling it can let the leader drain workers sooner. Compare both boolean states on the same plan and concurrency level.
Small nodes	This boolean does not add or remove worker slots. Leave it on unless measurements show a result-consumption bottleneck; size worker counts separately with max_parallel_workers_per_gather and the shared pools.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG19 Beta 3; this does not assert current Pigsty support for that historical or beta release.

Template	Effective value	Versus upstream boot	Source expression
OLTP	Unmodified	—	—
OLAP	Unmodified	—	—
CRIT	Unmodified	—	—
TINY	Unmodified	—	—

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG11–19 Beta 3 unmodified; OLAP: PG11–19 Beta 3 unmodified; CRIT: PG11–19 Beta 3 unmodified; TINY: PG11–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Treating the boolean as a degree-of-parallelism or worker-count setting.
Speaking of a ’larger’ value when the only choices are on and off.
Disabling participation without measuring the extra wait before workers produce the first tuples.
Enabling participation without checking whether the leader then drains a large worker result stream too slowly.

max_parallel_workers_per_gather · max_parallel_workers · enable_gathermerge · parallel_tuple_cost · parallel_setup_cost