CREATE_STATISTICS(7pg13)

💖 CREATE_STATISTICS 💖

okay so bestie, this is the PostgreSQL 13.23 page for CREATE_STATISTICS — the "define extended statistics" one, and honestly? it's a whole vibe. let's get into it 🫶

---

✨ NAME ✨

CREATE_STATISTICS — define extended statistics. that's it, that's the flex 💅

---

🦋 SYNOPSIS 🦋

CREATE STATISTICS [ IF NOT EXISTS ] statistics_name
    [ ( statistics_kind [, ... ] ) ]
    ON column_name, column_name [, ...]
    FROM table_name

look at that syntax. iconic. no notes 🌸

---

🎀 DESCRIPTION 🎀

so what does it do? CREATE STATISTICS creates a brand-new extended statistics object that tracks data about the table, foreign table, or materialized view you point it at. literally it's collecting receipts on your data 📊✨

the statistics object gets created in the current database, and it's owned by the user who issued the command — so whoever runs it, owns it, periodt.

if you give a schema name (like, for example, CREATE STATISTICS myschema.mystat ...) then the statistics object is created in that specified schema. otherwise it just lands in whatever the current schema is. and the name of the statistics object must be distinct from the name of any other statistics object in the same schema — no duplicates allowed, we don't do that here 🙅‍♀️

---

🌈 PARAMETERS 🌈

• IF NOT EXISTS — do not throw an error if a statistics object with the same name already exists. in that case a notice is issued instead. note that only the name of the statistics object is considered here — not the details of its definition. so like, same name? cool, we move on 💫
• statistics_name — the name (optionally schema-qualified) of the statistics object you're creating. name it something cute, idk 🎀
• statistics_kind — a statistics kind to be computed in this statistics object. currently supported kinds are:
  • ndistinct — enables n-distinct statistics
  • dependencies — enables functional dependency statistics
  • mcv — enables most-common values lists

if this clause is omitted, all supported statistics kinds are included in the statistics object. for more info, check out Section 14.2.2 and Section 71.2 📚

• column_name — the name of a table column to be covered by the computed statistics. at least two column names must be given, and the order of the column names is insignificant — doesn't matter which one you list first, it's not a ranking, bestie 💅
• table_name — the name (optionally schema-qualified) of the table containing the column(s) the statistics are computed on. see ANALYZE(7) for an explanation of the handling of inheritance and partitions — that's where the deets live 🔍

---

💜 NOTES 💜

you must be the owner of a table to create a statistics object reading it. no ownership, no stats, fr fr. but once it's created, the ownership of the statistics object is independent of the underlying table(s) — so it's off living its own life 😌

also, important heads up: extended statistics are not currently used by the planner for selectivity estimations made for table joins. this limitation will likely be removed in a future version of PostgreSQL. so like… it's giving "coming soon" energy ⏳

---

🔥 EXAMPLES 🔥

okay this first one is genuinely so good. we're making table t1 with two functionally dependent columns — meaning knowledge of a value in the first column is sufficient for determining the value in the other column. then we build functional dependency statistics on those columns:

CREATE TABLE t1 (
    a   int,
    b   int
);

INSERT INTO t1 SELECT i/100, i/500
                 FROM generate_series(1,1000000) s(i);

ANALYZE t1;

-- the number of matching rows will be drastically underestimated:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

CREATE STATISTICS s1 (dependencies) ON a, b FROM t1;

ANALYZE t1;

-- now the row count estimate is more accurate:
EXPLAIN ANALYZE SELECT * FROM t1 WHERE (a = 1) AND (b = 0);

so without functional-dependency statistics, the planner would assume those two WHERE conditions are independent, and would multiply their selectivities together to arrive at a much-too-small row count estimate 😭 tragic. but with such statistics, the planner recognizes that the WHERE conditions are redundant and does not underestimate the row count. ate and left no crumbs 👑

---

next one! create table t2 with two perfectly correlated columns (containing identical data), and an MCV list on those columns:

CREATE TABLE t2 (
    a   int,
    b   int
);

INSERT INTO t2 SELECT mod(i,100), mod(i,100)
                 FROM generate_series(1,1000000) s(i);

CREATE STATISTICS s2 (mcv) ON a, b FROM t2;

ANALYZE t2;

-- valid combination (found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 1);

-- invalid combination (not found in MCV)
EXPLAIN ANALYZE SELECT * FROM t2 WHERE (a = 1) AND (b = 2);

the MCV list gives the planner way more detailed information about the specific values that commonly appear in the table — plus an upper bound on the selectivities of combinations of values that do not appear in the table. which means it can generate better estimates in both cases. slay 💅✨

---

⭐ COMPATIBILITY ⭐

there is no CREATE STATISTICS command in the SQL standard. we're built different, iykyk 🤷‍♀️

---

👑 SEE ALSO 👑

• ALTER STATISTICS (ALTER_STATISTICS(7))
• DROP STATISTICS (DROP_STATISTICS(7))

---

and that's the whole page, bestie 🩷 this was PostgreSQL 13.23, dated 2025 — go forth and make some extended statistics, you've got this 🧚‍♀️💜