default_statistics_target

Sets the default detail level for column statistics collected by ANALYZE when a column has no explicit target. More detail can improve cardinality estimates at the cost of collection time and catalog space.

Note

Fact — official short description: “Sets the default statistics target.”

Identity

Type , Valueinteger: Upstream pg_settings type
Context , Valueuser: Settable by an ordinary user
Unit , Value—: Raw unit
Range , Value1 – 10000: 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 , Value100: 100

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	`100`	—	100

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

Tip

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

Workload	Guidance
OLTP	Keep the global target moderate and raise it for skewed columns that actually produce row-estimate errors. Re-run ANALYZE and compare estimated versus actual rows before and after.
OLAP	A higher baseline can help complex filters and joins, but use extended statistics for correlated predicates and budget the extra ANALYZE time after bulk loads.
Small nodes	A modest global increase is usually inexpensive, but per-column tuning remains more precise. Do not collect deep histograms for columns never used in predicates, grouping, or ordering.

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	`400`	different	`400`
OLAP	`1000`	different	`1000`
CRIT	`400`	different	`400`
TINY	`200`	different	`200`

Caution

Advice — pending human review. Fact from the current Pigsty template projection: OLTP: PG9.0–19 Beta 3 = 400 (dcs); OLAP: PG9.0–19 Beta 3 = 1000 (dcs); CRIT: PG9.0–19 Beta 3 = 400 (dcs); TINY: PG9.0–19 Beta 3 = 200 (dcs). Advice, pending human review — Editorial hypothesis, pending maintainer review: the profiles trade progressively more ANALYZE work for better planner estimates, with OLAP emphasizing plan quality and TINY limiting collection overhead.

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.

autovacuum_analyze_scale_factor · autovacuum_analyze_threshold · enable_partitionwise_join · plan_cache_mode · random_page_cost · effective_cache_size