PostgreSQL normally collects statistics for each column independently. That model works well when predicates on separate columns are close to independent, but it can misestimate row counts when the values move together.

A table might store country_code and currency_code, for example. If most rows with country_code = 'JP' also have currency_code = 'JPY', multiplying the two single-column selectivities treats a strong relationship as coincidence. The resulting cardinality estimate can be far below the actual row count.

Extended statistics add information about combinations of columns or expressions without creating an index. They affect planner estimates rather than providing a new access path.

Independent selectivity can distort a combined predicate

Suppose an accounts table contains geographic fields that are strongly correlated:

SELECT account_id
FROM accounts
WHERE country_code = 'JP'
  AND currency_code = 'JPY';

With only ordinary statistics, PostgreSQL has distribution information for country_code and currency_code separately. A simple independence model can combine those estimates as though the probability of one condition were unrelated to the other.

That assumption is often acceptable for unrelated attributes. It is a poor model when one value strongly constrains another.

A row-count error can propagate beyond the scan itself. Join order, join algorithm, aggregation strategy, and whether an index path appears attractive all depend on estimated cardinalities. Extended statistics target the estimate at the point where the missing cross-column relationship enters the plan.

Functional dependencies describe directional relationships

A dependency statistics object records the degree to which values in one set of columns determine values in another.

CREATE STATISTICS accounts_geo_dep (dependencies)
ON country_code, currency_code
FROM accounts;

ANALYZE accounts;

Creating the object defines what PostgreSQL should collect. ANALYZE, whether invoked directly or through automatic maintenance, performs the actual collection.

Functional dependency statistics are useful when a condition on one column makes another condition partly redundant. The relationship need not be a declared key constraint, and it need not be perfect. PostgreSQL records a dependency degree derived from sampled data.

This distinction matters for estimates. A query containing two correlated equality conditions should not necessarily receive the same selectivity reduction as two independent conditions. Dependency data lets the planner adjust that calculation.

Dependencies are not a substitute for integrity constraints. They describe observed data distribution for planning; they do not prevent future rows from violating the relationship.

Multivariate MCV lists capture specific value combinations

A global dependency does not describe every local pattern. Some combinations can be unusually frequent even when no broad functional relationship holds across the columns.

Multivariate most-common-value statistics address that case:

CREATE STATISTICS accounts_geo_mcv (mcv)
ON country_code, currency_code
FROM accounts;

ANALYZE accounts;

The resulting MCV data tracks common combinations and their observed frequencies. It also records baseline frequencies derived from the component values, giving the planner evidence that a particular combination occurs more or less often than an independence estimate suggests.

This is useful for skewed categorical data. Two columns can be only loosely related overall while a handful of pairs dominate a significant part of the table.

An MCV list is bounded rather than a complete frequency table. Its coverage depends on the statistics target and the sampled data. Rare combinations outside the list still require estimation from the remaining statistical model.

N-distinct statistics improve estimates for grouped combinations

Correlated columns also affect the expected number of groups.

SELECT country_code, currency_code, count(*)
FROM accounts
GROUP BY country_code, currency_code;

Multiplying separate distinct-value counts can greatly overstate the number of distinct pairs when only a limited set of combinations actually occurs.

An ndistinct statistics object stores estimates for distinct combinations:

CREATE STATISTICS accounts_geo_nd (ndistinct)
ON country_code, currency_code
FROM accounts;

ANALYZE accounts;

That information can improve estimates for operations such as grouping where the number of distinct combinations affects planner costing and plan shape.

The same statistics object can request several multivariate kinds:

CREATE STATISTICS accounts_geo
    (dependencies, mcv, ndistinct)
ON country_code, currency_code
FROM accounts;

ANALYZE accounts;

If the kind list is omitted for a multivariate definition, PostgreSQL collects all supported multivariate kinds.

Statistics change estimates, not physical access

CREATE STATISTICS can look superficially similar to CREATE INDEX because both name columns and create persistent database objects. Their runtime roles are different.

An index stores an access structure that an executor can scan. Extended statistics store distribution information consumed during planning. A statistics object cannot satisfy an ORDER BY, enforce uniqueness, or provide index tuples for a lookup.

The distinction also means extended statistics have no per-row index maintenance path. Their data is refreshed by ANALYZE from a sample of table rows. As table contents change, stale statistics can become less representative until analysis runs again.

Increasing the statistics target increases the sample used for ordinary and extended statistics, generally allowing finer estimates at the cost of additional analysis work and larger statistics data.

Expression statistics cover planner-visible transformations

Current PostgreSQL releases can collect statistics on expressions as well as plain columns. This is useful when predicates repeatedly apply the same transformation and ordinary column statistics do not describe the transformed distribution.

For example:

CREATE STATISTICS events_day_stats
ON (date_trunc('day', occurred_at))
FROM events;

ANALYZE events;

This form collects univariate statistics for the expression. Multivariate definitions can combine expressions and columns when the planner needs distribution information about their relationship.

Expression statistics still do not provide an index access path. If a query needs fast retrieval through the expression itself, an expression index is a separate physical design choice.

Extended statistics have a scope boundary

Extended statistics are primarily about relationships among values from one relation. PostgreSQL does not currently use them for selectivity estimates made for table joins.

That boundary prevents a common misapplication. Statistics on orders.customer_id and another column in orders can improve estimates for conditions within orders; they do not directly model the cross-table value relationship between orders.customer_id and customers.id.

The planner also needs predicates in forms where the collected statistics can be applied. Creating a large set of statistics objects does not guarantee that every estimate involving those columns changes.

Plan estimates show whether the model improved

The practical signal is the gap between estimated and actual rows in EXPLAIN (ANALYZE).

A useful comparison keeps the query and data fixed, inspects the estimate with ordinary statistics, adds a narrowly chosen extended statistics object, runs ANALYZE, and inspects the plan again. The target is not a particular plan node. The target is a cardinality model that better represents the data relationship.

The pg_stats_ext view exposes collected extended statistics in a readable form for relations the current user is permitted to inspect. It can help confirm that the intended object exists and contains dependency, distinct-count, or common-value data.

Extended statistics are most valuable when a planner error has a specific statistical cause: correlated predicates, skewed value combinations, or distinct combinations that single-column summaries cannot represent. They give PostgreSQL a richer model of the data while leaving storage and access structures unchanged.

PostgreSQL Database SQL Query Planning