select open change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

CONFIGURATION / QUERY TUNING

Controls the trade-off between planning time and query plan quality in GEQO.

Type
integer
Context
user
Measured default
5
Unit
Metadata snapshot
18

Definition PG 18 manual

Controls the trade-off between planning time and query plan quality in GEQO. This variable must be an integer in the range from 1 to 10. The default value is five. Larger values increase the time spent doing query planning, but also increase the likelihood that an efficient query plan will be chosen.

geqo_effort doesn't actually do anything directly; it is only used to compute the default values for the other variables that influence GEQO behavior (described below). If you prefer, you can set the other parameters by hand instead.

Measured default history
Version intervalDefault
9.0 – 195
Analysis & operational context

Authored guidance from the GUC source snapshot; the version-specific manual above is the definition reference. View source ↗

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.

Operational considerations

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.

Workload guidance

OLAP: For recurring many-table reports, test geqo_effort with multiple geqo_seed values and compare planning plus execution time. A single lucky seed is not a stable production policy.

OLTP: Keep geqo_effort at its upstream default unless planning time for many-way joins is measured as a problem. Prefer simplifying generated SQL or fixing join estimates before expanding a randomized search budget globally.

SMALL: Avoid increasing geqo_effort in ways that consume disproportionate planning CPU on a small host. The default adaptive values are safer than copying a large-system GEQO budget.

Related entries

Further reading

Definition snapshot: english-manuals:13d6203e1ff40cab4df69193fe7… · English manual source