force_parallel_mode

force_parallel_mode — Forces use of parallel query facilities. Observed in PG9.6–15; its last measured boot default is off in PG15, with user context. It was removed in PG16.

Note

Fact — official short description: “Forces use of parallel query facilities.”

Identity

Type , Valueenum: 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 , Valueoff, on, regress: — for non-enum types
Category , ValueDeveloper Options: Upstream classification
Latest boot value , Valueoff: off

Lifecycle

Fact	Value
First observed	PG9.6
Present in	PG9.6–15
Removed in	PG16
Introduction commit	`7c944bd90339` — Introduce a new GUC force_parallel_mode for testing purposes.
Commit date	2016-02-07
Discussion	—

Default history

Measured PG9.0–19 Beta 3 boot defaults
Versions	Raw `boot_val`	Unit	Human value
PG9.6–15	`off`	—	off

How it works

Through PG15, force_parallel_mode forced otherwise safe queries to run under a Gather so parallel-mode behavior could be tested even without an expected speedup. regress suppressed output differences for regression suites.

It did not make unsafe queries safe and could impose parallel-context restrictions even when no worker ran. The top-level Gather was diagnostic overhead rather than a plan hint.

PostgreSQL 16 removed this GUC and introduced debug_parallel_query for the testing role. Upgrade configurations must delete the old name and should not automatically enable the replacement in production. 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	Do not configure force_parallel_mode on current PostgreSQL. Remove it during upgrades; use any named successor only for the same controlled developer test, not as a production default.
OLAP	Analytical workload does not justify retaining the removed force_parallel_mode. Diagnose current versions with supported EXPLAIN, logs, or the documented replacement.
Small nodes	Delete force_parallel_mode from modern configurations. Unknown-parameter startup failure and diagnostic overhead outweigh any historical use.

Pigsty

Values use the fixed 8-vCPU, 32-GiB, 100-GiB SSD fixture and render the current Pigsty templates for PG15; 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: PG9.6–15 unmodified; OLAP: PG9.6–15 unmodified; CRIT: PG9.6–15 unmodified; TINY: PG9.6–15 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Leaving force_parallel_mode enabled after the bounded diagnostic or recovery task.
Running the experiment on the only copy of production data.
Underestimating log, core-file, temporary-file, WAL, CPU, or connection-slot amplification.
Treating a server that merely starts or completes a query as proof that data and behavior are correct.

debug_parallel_query · max_parallel_workers_per_gather · max_parallel_workers · parallel_setup_cost