PostgreSQL normally collects planner statistics for individual columns. That model works well when predicates can be estimated independently, but real schemas often contain related values. A country and region pair, a tenant identifier and status, or two derived date expressions can have distributions that single-column statistics cannot represent.

Extended statistics add a second layer of information across multiple columns or expressions. They do not create an access path and they do not change stored table data. Their role is narrower: provide the planner with a better model for cardinality estimation when values are related.

Independent estimates can distort combined selectivity

Consider a table containing customer addresses:

CREATE TABLE customer_address (
    id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    country_code text NOT NULL,
    region_code text NOT NULL,
    postal_code text NOT NULL
);

A predicate such as this combines two columns whose values are not independent:

SELECT id, postal_code
FROM customer_address
WHERE country_code = 'US'
  AND region_code = 'CA';

Without information about the relationship between country_code and region_code, the planner may combine separate selectivity estimates. That can produce a row-count estimate far from the actual result when a region value is strongly associated with a country value.

Cardinality estimates feed into plan costing. A poor estimate can affect join order, join method, scan choice, and other decisions even when suitable indexes already exist. Extended statistics address the estimate rather than the physical lookup mechanism.

Three multivariate statistics kinds cover different relationships

PostgreSQL supports dependencies, ndistinct, and mcv for multivariate statistics objects. A definition can request selected kinds:

CREATE STATISTICS customer_address_geo_stats
    (dependencies, ndistinct, mcv)
    ON country_code, region_code
    FROM customer_address;

ANALYZE customer_address;

CREATE STATISTICS defines the object. The statistical data is populated when ANALYZE processes the table, so creating the object alone does not immediately supply new distribution data to the planner.

Dependencies represent functional association

Dependency statistics describe cases where knowledge of one column provides information about another. A strict functional dependency is the clearest case, but PostgreSQL can also record partial dependency strength.

For correlated equality predicates, this can prevent the planner from treating both conditions as unrelated filters. The feature is about selectivity estimation; it does not enforce the relationship as a constraint.

N-distinct statistics describe combined cardinality

Single-column distinct counts cannot state how many distinct pairs occur across two columns. ndistinct statistics estimate the number of distinct combinations for the selected column set.

That information is useful for operations whose cost depends on grouped cardinality. A query grouping by both geographic columns is a direct example:

SELECT country_code, region_code, count(*)
FROM customer_address
GROUP BY country_code, region_code;

A better estimate of the number of groups gives the planner more accurate input for costing aggregation strategies.

MCV statistics preserve common combinations

A multivariate most-common-values list records frequent value combinations rather than frequent values from each column in isolation. This matters when particular combinations occur much more or less often than an independence assumption suggests.

For example, two individually common values do not necessarily form a common pair. Conversely, a specific pair can occupy a substantial portion of a table even when neither column alone captures enough context to describe that concentration.

Statistics can also cover expressions

Extended statistics are not limited to plain columns. PostgreSQL can collect statistics for expressions, including a single expression, and multivariate definitions can combine columns with expressions.

Suppose queries repeatedly filter on a timestamp transformed to a calendar boundary. Expression statistics can give the planner distribution information for the transformed value without requiring an expression index solely for estimation purposes.

An index and a statistics object solve different problems. An expression index supplies a physical access structure. Expression statistics supply distribution data. A workload may need either one or both depending on whether the issue is lookup cost, estimate quality, or both.

Scope limits matter when reading plans

Extended statistics are not a general correlation model for every planner decision. In current PostgreSQL releases, they are not used for selectivity estimates across table joins. Their main multivariate role applies to related values within the same table.

That boundary is significant when diagnosing a join with inaccurate row estimates. Adding statistics across columns of one relation can improve estimates for local filters, but it cannot directly encode a relationship between columns stored in separate relations.

The effect is best checked through plan estimates rather than assumed from the presence of a statistics object. EXPLAIN exposes estimated row counts, while EXPLAIN ANALYZE adds observed execution counts when running the statement is acceptable. The useful signal is whether the estimate for the relevant node moves closer to the observed cardinality after statistics are collected.

Statistics objects add analysis work, not index maintenance

Extended statistics are computed during ANALYZE. They do not add an index entry to each insert or update, but broader or more detailed statistics still increase the work and storage associated with statistics collection.

Definitions are most defensible when tied to predicates, grouping keys, or expressions that repeatedly expose a modeling gap. Creating large sets of speculative combinations can increase analysis cost without improving plans that matter.

PostgreSQL already has a capable single-column statistics model. Extended statistics fit the narrower cases where the missing information is the relationship between values. Treating that relationship as planner data keeps the fix aligned with the actual problem: cardinality estimation rather than data access.

PostgreSQL Database Query Planner Statistics