Query Tuning

• 1: constraint_exclusion
• 2: cpu_index_tuple_cost
• 3: cpu_operator_cost
• 4: cpu_tuple_cost
• 5: cursor_tuple_fraction
• 6: default_statistics_target
• 7: effective_cache_size
• 8: enable_async_append
• 9: enable_bitmapscan
• 10: enable_distinct_reordering
• 11: enable_eager_aggregate
• 12: enable_gathermerge
• 13: enable_group_by_reordering
• 14: enable_hashagg
• 15: enable_hashjoin
• 16: enable_incremental_sort
• 17: enable_indexonlyscan
• 18: enable_indexscan
• 19: enable_material
• 20: enable_memoize
• 21: enable_mergejoin
• 22: enable_nestloop
• 23: enable_parallel_append
• 24: enable_parallel_hash
• 25: enable_partition_pruning
• 26: enable_partitionwise_aggregate
• 27: enable_partitionwise_join
• 28: enable_presorted_aggregate
• 29: enable_self_join_elimination
• 30: enable_seqscan
• 31: enable_sort
• 32: enable_tidscan
• 33: from_collapse_limit
• 34: geqo
• 35: geqo_effort
• 36: geqo_generations
• 37: geqo_pool_size
• 38: geqo_seed
• 39: geqo_selection_bias
• 40: geqo_threshold
• 41: jit
• 42: jit_above_cost
• 43: jit_inline_above_cost
• 44: jit_optimize_above_cost
• 45: join_collapse_limit
• 46: min_eager_agg_group_size
• 47: min_parallel_index_scan_size
• 48: min_parallel_relation_size
• 49: min_parallel_table_scan_size
• 50: parallel_setup_cost
• 51: parallel_tuple_cost
• 52: plan_cache_mode
• 53: random_page_cost
• 54: recursive_worktable_factor
• 55: seq_page_cost

1 - constraint_exclusion

Identity

Lifecycle

Default history

How it works

constraint_exclusion lets the planner compare query predicates with CHECK constraints and omit relations whose constraints prove that they cannot match. partition limits that work to traditional inheritance children and UNION ALL arms; it is separate from declarative partition pruning.

The proof is attempted at planning time, so enabling it more broadly increases planning work even when no relation can be excluded. It relies on constraints that are visible and logically contradictory to the query conditions.

For declaratively partitioned tables, enable_partition_pruning is the primary control. constraint_exclusion remains useful for inheritance-based partitioning and carefully constructed constraint-backed UNION ALL views. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating constraint_exclusion 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.

Related parameters

enable_partition_pruning · from_collapse_limit · join_collapse_limit · default_statistics_target

References

• PostgreSQL 19 Beta 3 — constraint_exclusion
• PostgreSQL 19 release notes
• Machine-readable GUC export

2 - cpu_index_tuple_cost

Identity

Lifecycle

Default history

How it works

cpu_index_tuple_cost models the CPU work to process one index entry during an index scan. It is one term in estimated path cost and does not allocate resources or change executor behavior directly.

Planner cost units are arbitrary and only their ratios matter. Scaling all cost constants together leaves path ordering unchanged; changing one alters the balance between I/O, row processing, operators, and parallel overhead.

The value is consulted when a plan is built. Statistics, row-count estimates, cache assumptions, tablespace overrides, and enabled plan methods can outweigh a small change in this constant. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Interpreting the value as elapsed time or a hard resource limit.
• Tuning it to repair one query and regressing the wider workload.
• Changing cost constants before correcting statistics and cardinality estimates.
• Forgetting that only relative values influence path choice.

Related parameters

cpu_tuple_cost · cpu_operator_cost · random_page_cost · seq_page_cost · enable_indexscan

References

• PostgreSQL 19 Beta 3 — cpu_index_tuple_cost
• PostgreSQL 19 release notes
• Machine-readable GUC export

3 - cpu_operator_cost

Identity

Lifecycle

Default history

How it works

cpu_operator_cost models the CPU work for each operator or function invocation. It is one term in estimated path cost and does not allocate resources or change executor behavior directly.

Planner cost units are arbitrary and only their ratios matter. Scaling all cost constants together leaves path ordering unchanged; changing one alters the balance between I/O, row processing, operators, and parallel overhead.

The value is consulted when a plan is built. Statistics, row-count estimates, cache assumptions, tablespace overrides, and enabled plan methods can outweigh a small change in this constant. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Interpreting the value as elapsed time or a hard resource limit.
• Tuning it to repair one query and regressing the wider workload.
• Changing cost constants before correcting statistics and cardinality estimates.
• Forgetting that only relative values influence path choice.

Related parameters

cpu_tuple_cost · cpu_index_tuple_cost · jit_above_cost · seq_page_cost

References

• PostgreSQL 19 Beta 3 — cpu_operator_cost
• PostgreSQL 19 release notes
• Machine-readable GUC export

4 - cpu_tuple_cost

Identity

Lifecycle

Default history

How it works

cpu_tuple_cost models the CPU work to process one row. It is one term in estimated path cost and does not allocate resources or change executor behavior directly.

Planner cost units are arbitrary and only their ratios matter. Scaling all cost constants together leaves path ordering unchanged; changing one alters the balance between I/O, row processing, operators, and parallel overhead.

The value is consulted when a plan is built. Statistics, row-count estimates, cache assumptions, tablespace overrides, and enabled plan methods can outweigh a small change in this constant. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Interpreting the value as elapsed time or a hard resource limit.
• Tuning it to repair one query and regressing the wider workload.
• Changing cost constants before correcting statistics and cardinality estimates.
• Forgetting that only relative values influence path choice.

Related parameters

cpu_index_tuple_cost · cpu_operator_cost · seq_page_cost · random_page_cost · enable_seqscan

References

• PostgreSQL 19 Beta 3 — cpu_tuple_cost
• PostgreSQL 19 release notes
• Machine-readable GUC export

5 - cursor_tuple_fraction

Identity

Lifecycle

Default history

How it works

cursor_tuple_fraction tells the planner what fraction of a cursor’s result is expected to be fetched. Lower fractions give more weight to startup cost; 1.0 plans like an ordinary query that consumes the full result.

The estimate can change join order and access paths by preferring a fast first row even when total execution would be slower. It does not stop FETCH after that fraction and is not a row limit.

It is consulted at planning time for cursor plans. Application behavior matters: cursors used for pagination, early exit, or full export have very different appropriate fractions. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating cursor_tuple_fraction 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.

Related parameters

plan_cache_mode · random_page_cost · enable_nestloop · enable_indexscan

References

• PostgreSQL 19 Beta 3 — cursor_tuple_fraction
• PostgreSQL 19 release notes
• Machine-readable GUC export

6 - default_statistics_target

Identity

Lifecycle

Default history

How it works

The target limits the number of entries in most-common-value lists and histogram bins stored for a column. The planner uses those statistics to estimate row counts, which feed access-path, join-order, and join-method decisions.

ANALYZE samples large tables rather than reading every row. Its sample size is driven by the largest statistics target among the columns being analyzed, so increasing the target raises analysis time and space roughly in proportion.

ALTER TABLE … ALTER COLUMN … SET STATISTICS overrides the global default for a column. Correlation between columns is a separate problem that normally requires CREATE STATISTICS rather than simply increasing this setting.

Tuning advice

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.

Common pitfalls

• Changing the setting does not refresh existing statistics; ANALYZE must run afterward.
• Higher single-column targets do not model cross-column correlation by themselves.
• A high global target increases ANALYZE work even for unimportant columns.
• Partitioned parents can require manual ANALYZE because child changes do not trigger it.
• Approximate sampling can still produce estimation error and plan variation.

Related parameters

autovacuum_analyze_scale_factor · autovacuum_analyze_threshold · enable_partitionwise_join · plan_cache_mode · random_page_cost · effective_cache_size

References

• PostgreSQL 19 Beta 3 — default_statistics_target
• PostgreSQL 18: Statistics Used by the Planner
• PostgreSQL 18: ANALYZE
• PostgreSQL 19 release notes
• Machine-readable GUC export

7 - effective_cache_size

Identity

Lifecycle

Default history

How it works

effective_cache_size is a cost-model input. Higher values make index scans look more attractive; lower values make sequential scans more attractive.

The estimate should reflect both shared_buffers and the portion of the operating-system page cache likely to hold PostgreSQL data, while accounting for overlap and for concurrent queries sharing the same cache capacity.

Changing this parameter does not resize PostgreSQL shared memory, reserve kernel cache, or guarantee that pages remain cached between queries. Its effect is indirect, through plan selection.

Tuning advice

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.

Common pitfalls

• Expecting the setting to allocate or reserve memory.
• Setting it equal to installed RAM without subtracting memory unavailable to PostgreSQL caching.
• Ignoring that concurrent queries on different data sets share the effective cache.
• Overstating it and then attributing index-heavy plan choices to unrelated cost parameters.

Related parameters

shared_buffers · random_page_cost · seq_page_cost · effective_io_concurrency · max_connections

References

• PostgreSQL 19 Beta 3 — effective_cache_size
• PostgreSQL 18: Using EXPLAIN
• Pigsty: Parameter Optimization Policy
• PostgreSQL 19 release notes
• Machine-readable GUC export

8 - enable_async_append

Identity

Lifecycle

Default history

How it works

enable_async_append controls whether the planner may choose async-aware Append, which can overlap waits while reading multiple asynchronous-capable children.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_async_append as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_parallel_append · effective_io_concurrency · io_method · enable_partition_pruning

References

• PostgreSQL 19 Beta 3 — enable_async_append
• PostgreSQL 19 release notes
• Machine-readable GUC export

9 - enable_bitmapscan

Identity

Lifecycle

Default history

How it works

enable_bitmapscan controls whether the planner may choose bitmap index and bitmap heap scans, which combine tuple locations before visiting heap pages.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_bitmapscan as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_indexscan · enable_seqscan · random_page_cost · work_mem · effective_io_concurrency

References

• PostgreSQL 19 Beta 3 — enable_bitmapscan
• PostgreSQL 19 release notes
• Machine-readable GUC export

10 - enable_distinct_reordering

Identity

Lifecycle

Default history

How it works

enable_distinct_reordering controls whether the planner may choose reordering DISTINCT keys to match useful input pathkeys and avoid or reduce sorting.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_distinct_reordering as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_sort · enable_incremental_sort · enable_presorted_aggregate · work_mem

References

• PostgreSQL 19 Beta 3 — enable_distinct_reordering
• PostgreSQL 19 release notes
• Machine-readable GUC export

11 - enable_eager_aggregate

Identity

Lifecycle

Default history

How it works

PostgreSQL describes enable_eager_aggregate as follows: “Enables eager aggregation.” It can be changed per session, which makes plan or behavior comparisons possible without changing every workload. The atlas measures it in PG19 Beta 3; boot_val is the compiled or initialized baseline, not proof of a running cluster’s effective setting.

Eager aggregation partially pushes aggregation below a join so fewer rows may cross the join, then finalizes the result after all relations are joined. It is considered only when estimated average group size reaches min_eager_agg_group_size; estimates, grouping semantics, memory, and alternative join paths still determine whether the planner selects it.

Read it together with min_eager_agg_group_size, enable_hashagg, enable_partitionwise_aggregate, work_mem. Check SHOW and pg_settings on the target server, verify the source and pending_restart fields, and compare workload, logs, and resource metrics before and after any change.

Tuning advice

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.

Common pitfalls

• Treating the measured boot_val for enable_eager_aggregate as proof of the effective value on an initialized or managed cluster.
• Applying a change as though it were immediate while pg_settings reports user context.
• Changing this setting in isolation without checking the linked limits, observability, and rollback path.
• Depending on beta behavior in production without retesting the PostgreSQL 19 final release.

Related parameters

min_eager_agg_group_size · enable_hashagg · enable_partitionwise_aggregate · work_mem · hash_mem_multiplier

References

• PostgreSQL 19 Beta 3 — enable_eager_aggregate
• PostgreSQL 19 release notes
• Machine-readable GUC export

12 - enable_gathermerge

Identity

Lifecycle

Default history

How it works

enable_gathermerge controls whether the planner may choose Gather Merge, which preserves the order produced by parallel workers while merging their streams.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_gathermerge as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

max_parallel_workers_per_gather · enable_sort · enable_incremental_sort · parallel_leader_participation

References

• PostgreSQL 19 Beta 3 — enable_gathermerge
• PostgreSQL 19 release notes
• Machine-readable GUC export

13 - enable_group_by_reordering

Identity

Lifecycle

Default history

How it works

enable_group_by_reordering controls whether the planner may choose reordering GROUP BY keys to match a child’s pathkeys and exploit preordered input.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_group_by_reordering as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_sort · enable_incremental_sort · enable_hashagg · enable_presorted_aggregate

References

• PostgreSQL 19 Beta 3 — enable_group_by_reordering
• PostgreSQL 19 release notes
• Machine-readable GUC export

14 - enable_hashagg

Identity

Lifecycle

Default history

How it works

enable_hashagg controls whether the planner may choose hashed aggregation, which groups rows in hash tables instead of sorted streams.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_hashagg as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

work_mem · hash_mem_multiplier · enable_sort · enable_partitionwise_aggregate

References

• PostgreSQL 19 Beta 3 — enable_hashagg
• PostgreSQL 19 release notes
• Machine-readable GUC export

15 - enable_hashjoin

Identity

Lifecycle

Default history

How it works

enable_hashjoin controls whether the planner may choose hash joins, which build a hash table for one input and probe it with the other.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_hashjoin as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

work_mem · hash_mem_multiplier · enable_parallel_hash · enable_mergejoin · enable_nestloop

References

• PostgreSQL 19 Beta 3 — enable_hashjoin
• PostgreSQL 19 release notes
• Machine-readable GUC export

16 - enable_incremental_sort

Identity

Lifecycle

Default history

How it works

enable_incremental_sort controls whether the planner may choose incremental sort, which sorts within groups that are already ordered by a prefix of the required keys.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_incremental_sort as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_sort · enable_gathermerge · work_mem · enable_presorted_aggregate

References

• PostgreSQL 19 Beta 3 — enable_incremental_sort
• PostgreSQL 19 release notes
• Machine-readable GUC export

17 - enable_indexonlyscan

Identity

Lifecycle

Default history

How it works

enable_indexonlyscan controls whether the planner may choose index-only scans, which can return index tuples without heap reads when visibility information permits.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

It has no effect unless enable_indexscan is also on, and heap visits still occur for pages not marked all-visible. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_indexonlyscan as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• It has no effect unless enable_indexscan is also on, and heap visits still occur for pages not marked all-visible.

Related parameters

enable_indexscan · enable_bitmapscan · enable_seqscan · random_page_cost · track_counts

References

• PostgreSQL 19 Beta 3 — enable_indexonlyscan
• PostgreSQL 19 release notes
• Machine-readable GUC export

18 - enable_indexscan

Identity

Lifecycle

Default history

How it works

enable_indexscan controls whether the planner may choose ordinary index scans; this switch also gates consideration of index-only scans.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_indexscan as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_indexonlyscan · enable_bitmapscan · enable_seqscan · random_page_cost · effective_cache_size

References

• PostgreSQL 19 Beta 3 — enable_indexscan
• PostgreSQL 19 release notes
• Machine-readable GUC export

19 - enable_material

Identity

Lifecycle

Default history

How it works

enable_material controls whether the planner may choose planner-inserted Materialize nodes that preserve an input for rescans or isolate execution properties.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

Turning it off cannot remove materialization that is required for correctness; it only prevents optional planner insertion. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_material as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• Turning it off cannot remove materialization that is required for correctness; it only prevents optional planner insertion.

Related parameters

work_mem · temp_file_limit · enable_memoize · enable_nestloop

References

• PostgreSQL 19 Beta 3 — enable_material
• PostgreSQL 19 release notes
• Machine-readable GUC export

20 - enable_memoize

Identity

Lifecycle

Default history

How it works

enable_memoize controls whether the planner may choose Memoize nodes that cache parameterized inner-scan results inside nested-loop joins.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_memoize as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_nestloop · work_mem · enable_material · cpu_operator_cost

References

• PostgreSQL 19 Beta 3 — enable_memoize
• PostgreSQL 19 release notes
• Machine-readable GUC export

21 - enable_mergejoin

Identity

Lifecycle

Default history

How it works

enable_mergejoin controls whether the planner may choose merge joins, which consume inputs ordered on compatible join keys.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_mergejoin as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_hashjoin · enable_nestloop · enable_sort · enable_indexscan · work_mem

References

• PostgreSQL 19 Beta 3 — enable_mergejoin
• PostgreSQL 19 release notes
• Machine-readable GUC export

22 - enable_nestloop

Identity

Lifecycle

Default history

How it works

enable_nestloop controls whether the planner may choose nested-loop joins, including parameterized inner scans that may be best for small outer relations.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

Turning it off only discourages nested loops because some joins have no other correct implementation. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_nestloop as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• Turning it off only discourages nested loops because some joins have no other correct implementation.

Related parameters

enable_hashjoin · enable_mergejoin · enable_memoize · random_page_cost · work_mem

References

• PostgreSQL 19 Beta 3 — enable_nestloop
• PostgreSQL 19 release notes
• Machine-readable GUC export

23 - enable_parallel_append

Identity

Lifecycle

Default history

How it works

enable_parallel_append controls whether the planner may choose parallel-aware Append, allowing workers to divide work across child plans.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_parallel_append as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_async_append · max_parallel_workers_per_gather · enable_partition_pruning · parallel_leader_participation

References

• PostgreSQL 19 Beta 3 — enable_parallel_append
• PostgreSQL 19 release notes
• Machine-readable GUC export

24 - enable_parallel_hash

Identity

Lifecycle

Default history

How it works

enable_parallel_hash controls whether the planner may choose parallel hash, in which workers cooperate to build and probe a shared hash table.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

It has no effect when enable_hashjoin is off and also depends on a parallel-safe plan and available workers. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_parallel_hash as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• It has no effect when enable_hashjoin is off and also depends on a parallel-safe plan and available workers.

Related parameters

enable_hashjoin · max_parallel_workers_per_gather · work_mem · hash_mem_multiplier

References

• PostgreSQL 19 Beta 3 — enable_parallel_hash
• PostgreSQL 19 release notes
• Machine-readable GUC export

25 - enable_partition_pruning

Identity

Lifecycle

Default history

How it works

enable_partition_pruning controls whether the planner may choose plan-time and execution-time elimination of partitions contradicted by query predicates.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_partition_pruning as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

constraint_exclusion · enable_partitionwise_join · enable_partitionwise_aggregate · plan_cache_mode

References

• PostgreSQL 19 Beta 3 — enable_partition_pruning
• PostgreSQL 19 release notes
• Machine-readable GUC export

26 - enable_partitionwise_aggregate

Identity

Lifecycle

Default history

How it works

enable_partitionwise_aggregate controls whether the planner may choose per-partition grouping or aggregation, with later finalization when grouping keys do not contain partition keys.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

It can multiply work_mem-limited nodes and planning effort roughly with the number of participating partitions. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_partitionwise_aggregate as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• It can multiply work_mem-limited nodes and planning effort roughly with the number of participating partitions.

Related parameters

enable_partitionwise_join · enable_partition_pruning · work_mem · enable_hashagg · max_parallel_workers_per_gather

References

• PostgreSQL 19 Beta 3 — enable_partitionwise_aggregate
• PostgreSQL 19 release notes
• Machine-readable GUC export

27 - enable_partitionwise_join

Identity

Lifecycle

Default history

How it works

enable_partitionwise_join controls whether the planner may choose joining one-to-one matching partitions when join keys contain compatible partition keys.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

It can multiply work_mem-limited nodes and planning effort roughly with the number of participating partitions. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_partitionwise_join as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• It can multiply work_mem-limited nodes and planning effort roughly with the number of participating partitions.

Related parameters

enable_partitionwise_aggregate · enable_partition_pruning · work_mem · join_collapse_limit · max_parallel_workers_per_gather

References

• PostgreSQL 19 Beta 3 — enable_partitionwise_join
• PostgreSQL 19 release notes
• Machine-readable GUC export

28 - enable_presorted_aggregate

Identity

Lifecycle

Default history

How it works

enable_presorted_aggregate controls whether the planner may choose plans that deliver input already ordered for aggregate ORDER BY or DISTINCT clauses.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_presorted_aggregate as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_sort · enable_incremental_sort · enable_group_by_reordering · work_mem

References

• PostgreSQL 19 Beta 3 — enable_presorted_aggregate
• PostgreSQL 19 release notes
• Machine-readable GUC export

29 - enable_self_join_elimination

Identity

Lifecycle

Default history

How it works

enable_self_join_elimination controls whether the planner may choose removing provably redundant self-joins on plain tables when uniqueness and predicates preserve semantics.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The optimization is limited to plain tables and requires proofs that removing the duplicate relation preserves results. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_self_join_elimination as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The optimization is limited to plain tables and requires proofs that removing the duplicate relation preserves results.

Related parameters

join_collapse_limit · from_collapse_limit · enable_nestloop · enable_hashjoin

References

• PostgreSQL 19 Beta 3 — enable_self_join_elimination
• PostgreSQL 19 release notes
• Machine-readable GUC export

30 - enable_seqscan

Identity

Lifecycle

Default history

How it works

enable_seqscan controls whether the planner may choose sequential scans, which visit a relation in physical page order.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

Turning it off only discourages sequential scans because some queries still have no usable alternative. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_seqscan as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• Turning it off only discourages sequential scans because some queries still have no usable alternative.

Related parameters

enable_indexscan · enable_bitmapscan · seq_page_cost · random_page_cost · effective_cache_size

References

• PostgreSQL 19 Beta 3 — enable_seqscan
• PostgreSQL 19 release notes
• Machine-readable GUC export

31 - enable_sort

Identity

Lifecycle

Default history

How it works

enable_sort controls whether the planner may choose explicit Sort nodes when no usable input order satisfies the requested pathkeys.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

Turning it off only discourages explicit sorting because correctness can still require a sort. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_sort as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• Turning it off only discourages explicit sorting because correctness can still require a sort.

Related parameters

work_mem · temp_file_limit · enable_incremental_sort · enable_gathermerge · trace_sort

References

• PostgreSQL 19 Beta 3 — enable_sort
• PostgreSQL 19 release notes
• Machine-readable GUC export

32 - enable_tidscan

Identity

Lifecycle

Default history

How it works

enable_tidscan controls whether the planner may choose TID scans for predicates that identify physical tuple locations such as ctid.

It is consulted while a plan is built. A session-level change is useful for comparing EXPLAIN alternatives, but an already cached plan is not retroactively rewritten; invalidation or replanning is required to observe a different choice.

The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Treating enable_tidscan as a query hint even though it affects every plan built in its scope.
• Testing an already cached prepared plan and concluding that the setting has no effect.
• Masking stale statistics or cardinality errors by disabling a plan method globally.
• The switch changes which candidate paths the planner may cost; it does not make the chosen method faster by itself.

Related parameters

enable_indexscan · enable_seqscan · random_page_cost · cpu_tuple_cost

References

• PostgreSQL 19 Beta 3 — enable_tidscan
• PostgreSQL 19 release notes
• Machine-readable GUC export

33 - from_collapse_limit

Identity

Lifecycle

Default history

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

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.

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.

Related parameters

join_collapse_limit · geqo_threshold · geqo · plan_cache_mode

References

• PostgreSQL 19 Beta 3 — from_collapse_limit
• PostgreSQL 19 release notes
• Machine-readable GUC export

34 - geqo

Identity

Lifecycle

Default history

How it works

It selects the heuristic GEQO join-order search instead of exhaustive dynamic programming for sufficiently large join problems.

GEQO trades bounded planning time for a heuristic search that can miss the best join order. It still costs scan and join paths with the ordinary planner cost model after constructing candidates.

The setting is read during planning, and GEQO’s randomized search means plan quality can vary with seed and search budget. Collapse limits can change the number of relations exposed to the join search and therefore whether the threshold is crossed. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Judging plan quality from one randomized GEQO run.
• Changing a GEQO knob without accounting for geqo_threshold and collapse limits.
• Spending much more planning CPU for a marginal or unstable execution-time gain.
• Assuming GEQO guarantees the globally best join order.

Related parameters

geqo_threshold · geqo_effort · geqo_pool_size · geqo_generations · join_collapse_limit

References

• PostgreSQL 19 Beta 3 — geqo
• PostgreSQL 19 release notes
• Machine-readable GUC export

35 - geqo_effort

Identity

Lifecycle

Default history

How it works

It is a convenience knob from 1 to 10 that derives defaults for pool size and generations; it has no direct step in the genetic algorithm.

GEQO trades bounded planning time for a heuristic search that can miss the best join order. It still costs scan and join paths with the ordinary planner cost model after constructing candidates.

The setting is read during planning, and GEQO’s randomized search means plan quality can vary with seed and search budget. Collapse limits can change the number of relations exposed to the join search and therefore whether the threshold is crossed. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Judging plan quality from one randomized GEQO run.
• Changing a GEQO knob without accounting for geqo_threshold and collapse limits.
• Spending much more planning CPU for a marginal or unstable execution-time gain.
• Assuming GEQO guarantees the globally best join order.

Related parameters

geqo · geqo_pool_size · geqo_generations · geqo_selection_bias · geqo_threshold

References

• PostgreSQL 19 Beta 3 — geqo_effort
• PostgreSQL 19 release notes
• Machine-readable GUC export

36 - geqo_generations

Identity

Lifecycle

Default history

How it works

It sets the number of evolutionary iterations; zero derives a value from the selected pool size.

GEQO trades bounded planning time for a heuristic search that can miss the best join order. It still costs scan and join paths with the ordinary planner cost model after constructing candidates.

The setting is read during planning, and GEQO’s randomized search means plan quality can vary with seed and search budget. Collapse limits can change the number of relations exposed to the join search and therefore whether the threshold is crossed. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Judging plan quality from one randomized GEQO run.
• Changing a GEQO knob without accounting for geqo_threshold and collapse limits.
• Spending much more planning CPU for a marginal or unstable execution-time gain.
• Assuming GEQO guarantees the globally best join order.

Related parameters

geqo · geqo_pool_size · geqo_effort · geqo_seed · geqo_selection_bias

References

• PostgreSQL 19 Beta 3 — geqo_generations
• PostgreSQL 19 release notes
• Machine-readable GUC export

37 - geqo_pool_size

Identity

Lifecycle

Default history

How it works

It sets the number of candidate join orders in the genetic population; zero asks PostgreSQL to derive a value from effort and query size.

GEQO trades bounded planning time for a heuristic search that can miss the best join order. It still costs scan and join paths with the ordinary planner cost model after constructing candidates.

The setting is read during planning, and GEQO’s randomized search means plan quality can vary with seed and search budget. Collapse limits can change the number of relations exposed to the join search and therefore whether the threshold is crossed. Its user context permits session- or transaction-local changes; newly performed or newly planned work sees the value.

Tuning advice

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.

Common pitfalls

• Judging plan quality from one randomized GEQO run.
• Changing a GEQO knob without accounting for geqo_threshold and collapse limits.
• Spending much more planning CPU for a marginal or unstable execution-time gain.
• Assuming GEQO guarantees the globally best join order.

Related parameters

geqo · geqo_effort · geqo_generations · geqo_selection_bias · geqo_seed

References

• PostgreSQL 19 Beta 3 — geqo_pool_size
• PostgreSQL 19 release notes
• Machine-readable GUC export

38 - geqo_seed

Identity

Lifecycle

Default history