from_collapse_limit

from_collapse_limit — Sets the FROM-list size beyond which subqueries are not collapsed. Observed in PG9.0–19 Beta 3; its last measured boot default is 8 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: “Sets the FROM-list size beyond which subqueries are not collapsed.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value1 – 2147483647: Raw limits in the last observed version
Enum values , Value—: — for non-enum types
Category , ValueQuery Tuning / Other Planner Options: Upstream classification
Latest boot value , Value8: 8

Lifecycle

Fact	Value
First observed	PG9.0 (research boundary)
Present in	PG9.0–19 Beta 3
Removed in	No
Introduction commit	Not asserted: predates the PG9.0 research boundary
Commit date	—
Discussion	—

Default history

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

How it works

from_collapse_limit bounds how far the planner merges eligible subqueries into the parent FROM list. Flattening exposes more join orders and predicate movement opportunities but enlarges the search space.

If flattening would produce more FROM items than the limit, the subquery boundary is retained. Smaller values can reduce planning time while hiding a better global join order.

The resulting relation count interacts with join_collapse_limit and geqo_threshold; raising this limit can unexpectedly move the query from exhaustive planning into GEQO. 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 from_collapse_limit at its upstream default unless representative plans show a repeatable, workload-wide problem. Test a local override first and include planning latency as well as execution latency.
OLAP	Analytical SQL can make from_collapse_limit more visible because joins, cursors, or recursion are larger. Benchmark the full statement family and inspect estimates rather than copying a single successful value.
Small nodes	On a small host, avoid increasing planning search or memory pressure through from_collapse_limit without a measured benefit. Prefer query-local structure or a scoped role setting over a cluster-wide override.

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: PG9.0–19 Beta 3 unmodified; OLAP: PG9.0–19 Beta 3 unmodified; CRIT: PG9.0–19 Beta 3 unmodified; TINY: PG9.0–19 Beta 3 unmodified. No Pigsty-specific rationale is inferred from an absent override.

Common pitfalls

Treating from_collapse_limit as an executor resource limit rather than a planning assumption or policy.
Testing only one parameter set or one data distribution.
Expecting an already cached plan to be rewritten automatically.
Using a global override to hide stale statistics or fragile SQL structure.

join_collapse_limit · geqo_threshold · geqo · plan_cache_mode