SQL SQL In Depth
0%
lesson statistics histograms cardinality

Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms

7 min read Module 4.2: The Query Planner, Cost-Based Optimizer & EXPLAIN Updated Oct 26, 2026
📄 Cheat Sheet
Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms — Database Systems & SQL Architecture Lecture
CMU Database Group (Andy Pavlo) Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms — Database Systems & SQL Architecture Lecture Watch on YouTube ↗

Builds first-principles mastery of Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms with concrete query execution trees, storage page layouts, and production tuning trade-offs.

0:00 / 3:53

1. First-Principles Mental Model & Relational Mechanics

Every SQL statement in Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms compiles down to a deterministic tree of relational algebra operators acting on physical pages in the buffer pool. At the logical layer, How ANALYZE samples pages to populate pg_statistic / sqlite_stat1 with Most Common Values (MCV) lists and equi-depth histogram bounds. Rather than mutating global variables imperatively, declarative SQL specifies the mathematical properties of the desired output relation while delegating physical access path selection to the cost-based query optimizer.

When the database engine processes table-statistics-histograms-cardinality within The Query Planner, Cost-Based Optimizer & EXPLAIN, it enforces strict invariants over tuple domains, attribute visibility, and I/O page budgets. Understanding the boundary between logical relational semantics (what rows qualify) and physical execution (whether the engine performs a sequential heap scan, a B+Tree range seek, or an in-memory hash probe) is the defining skill of a Staff Database Engineer.

Formal Relational & Cost Invariant — Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms

Let relation RR contain NN tuples stored across BB physical 8KB pages (B≈⌈N/tuples_per_page⌉B \approx \lceil N / \text{tuples\_per\_page} \rceil). Evaluating Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms maintains the relational closure and I/O cost bound:

CostI/O(R)=Bseq⋅cseq+log⁡F(N)⋅crandom,σθ(πA(R))⊆Dom(A)\text{Cost}_{\text{I/O}}(R) = B_{\text{seq}} \cdot c_{\text{seq}} + \log_{F}(N) \cdot c_{\text{random}}, \quad \sigma_{\theta}(\pi_{A}(R)) \subseteq \text{Dom}(A)

Where F≈250–500F \approx 250\text{--}500 is the B+Tree page fanout, σθ\sigma_{\theta} denotes Three-Valued Logic predicate selection over statistics, and πA\pi_{A} projects the target attribute schema without violating domain constraints.

2. Database Table Schema, Execution Pipeline & Visual Architecture

Tracing how Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms flows through the parser, catalog binder, cost-based optimizer, and physical executor reveals exactly where latency and cardinality bugs originate:

  • Stage 1 — Lexical Parsing & Catalog Binding (statistics): The SQL parser builds an Abstract Syntax Tree (AST) and resolves every relation, column identifier, and data type against system catalog tables (such as pg_class, pg_attribute, or sqlite_master).
  • Stage 2 — Logical Rewrite & Algebraic Simplification (histograms): The planner normalizes predicates, pushes selective filters as close to the storage scan as possible, and verifies whether Three-Valued NULL semantics permit subquery unnesting or join elimination.
  • Stage 3 — Cost Estimation & Physical Operator Selection (cardinality): Using histogram boundaries, Most Common Values (MCV), and Number of Distinct Values (NDV), the optimizer selects the minimum-cost physical plan and streams tuples through the execution pipeline.
Table Statistics (ANALYZE): Null Fraction, NDV, Mos... — B+Tree Index Seek & Heap Page Fetch Module M11 · idx_orders_customer_status (customer_id, status) · O(log_B N) Traversal ROOT PAGE #01 (Internal Directory) [ cust_id < 3 ] | [ cust_id >= 3 ] LEAF PAGE #14 (Doubly-Linked) (1, 'completed') -> ctid(0,1) (1, 'completed') -> ctid(0,3) (2, 'completed') -> ctid(0,2) next_leaf_page = #15 ───► LEAF PAGE #15 (Sibling) (3, 'completed') -> ctid(0,4) (3, 'refunded') -> ctid(0,9) (5, 'completed') -> ctid(0,6) 8KB HEAP PAGE #0 (orders) ctid(0,1): id=1001 | $1050.00 ctid(0,2): id=1002 | $420.00 ctid(0,3): id=1003 | $950.00 Visibility Map = 1 (Index-Only OK)
flowchart LR A["1. FROM / JOIN (statistics)"] --> B["2. WHERE / 3VL Filter (histograms)"] B --> C["3. GROUP BY / WINDOW OVER"] C --> D["4. SELECT Projection & ORDER BY (cardinality)"]

3. Interactive Table-Level & Storage Engine Simulator

Use the interactive simulator below to step through Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms at the tuple and page level. Observe how input rows, intermediate filter/join states, NULL badges, and physical page reads evolve at each step:

Cost-Based Optimizer (CBO): MCV/Histogram Selectivity & Scan Operator Transition
Seq vs Bitmap vs Index

Watch the query planner compute selectivity from MCVs and equi-depth histograms, then pick between Index Scan, Bitmap Heap Scan, and Seq Scan as selectivity rises.

Step 1 / 6
Custom Input:
Timeline

Invariant & State

Relation initialized with 4 tuples across schema (selectivity_pct, est_rows, index_scan_cost, bitmap_scan_cost, seq_scan_cost, winner) — preset: Selectivity Sweep: 0.1% (Index) → 5% (Bitmap) → 35% (Seq Scan).
🌳 Live 2D Hierarchical Tree Topology — Cost-Based Optimizer (CBO): MCV/Histogram Selectivity & Scan Operator Transition Visited/Active Pivot/Root Resolved
Tuple #0 0.05%… [0] 0.80%… [1] 4.50%… [2] 28.0%… [3]
📋 Cost-Based Optimizer (CBO): MCV/Histogram Selectivity & Scan Operator Transition — Initial Relation State 4 row(s)
selectivity_pctest_rowsindex_scan_costbitmap_scan_costseq_scan_costwinnerState
0.05%5018.442.01850.0Index Scan ✓CURSOR START
0.80%800295.0180.21850.0Bitmap Heap Scan ✓
4.50%4,5001620.0610.51850.0Bitmap Heap Scan ✓
28.0%28,0009840.02410.01850.0Seq Scan ✓
[0]0.05%:18.4Tuple #0
[1]0.80%:295.0
[2]4.50%:1620.0
[3]28.0%:9840.0
Input Tuples
4
Columns
6
Preset Mode
selectivity
Pipeline Stage
1. Initial Scan
[Step 1] Initialized Cost-Based Optimizer (CBO): MCV/Histogram Selectivity & Scan Operator Transition (Selectivity Sweep: 0.1% (Index) → 5% (Bitmap) → 35% (Seq Scan)) with 4 base rows.

4. Live WASM SQL Lab, Clause-by-Clause Visualizer & Automated Test Checker

Execute, edit, and test the production SQL query below directly in your browser using the embedded WebAssembly SQLite 3 engine. Click ▶ Run Query to execute, 🔍 Step Clauses to inspect the live intermediate table after FROM/JOIN, WHERE, GROUP BY, HAVING, WINDOW, SELECT, and ORDER BY, or ✓ Check SQL Tests to run automated relational assertions against the reference result:

SQL · WASM15 lines
-- Dataset: ecommerce | Composite Index Seek (idx_orders_customer_status) & SARGable Plan
SELECT
  o.order_id,
  o.customer_id,
  c.name AS customer_name,
  o.status,
  o.created_at,
  ROUND(o.total_cents / 100.0, 2) AS total_usd
FROM orders AS o
INNER JOIN customers AS c
  ON c.customer_id = o.customer_id
WHERE o.status = 'completed'
  AND o.created_at >= '2025-02-01'
ORDER BY o.created_at DESC, o.order_id DESC
LIMIT 10;

5. Cross-Engine Dialect & Cost Comparison Matrix

While the SQL ISO standard defines the logical behavior of Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms, production storage engines differ in how they execute, lock, and index the underlying tuples:

Database Engine Primary Storage & Access Mechanism I/O & CPU Complexity Production Caveat for Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms
PostgreSQL 17 Heap Tuple Store (ctid) + B-Tree / GIN / BRIN + MVCC (xmin/xmax) O(log⁡BN)O(\log_B N) seek / O(N)O(N) scan Requires ANALYZE statistics and Visibility Map bits for Index-Only Scans.
SQLite 3.46 (WASM) B+Tree Table (rowid clustered) + Covering Secondary B-Trees O(log⁡BN)O(\log_B N) B+Tree traversal Runs in-process with zero network RTT; inspect EXPLAIN QUERY PLAN for USE TEMP B-TREE.
MySQL 8.4 (InnoDB) Clustered Primary Key B+Tree + Undo Log Rollback Segments O(log⁡BN)O(\log_B N) PK / 2×O(log⁡BN)2 \times O(\log_B N) Secondary Secondary indexes store the Primary Key value; wide PKs amplify secondary index footprint.
DuckDB / ClickHouse Columnar Vectorized Chunks + Zone Maps (Min/Max Skipping) O(N/SIMD_Width)O(N / \text{SIMD\_Width}) vectorized scan Excels at wide analytical scans and aggregations; avoid single-row OLTP point mutations.

6. Under the Hood: Storage & Execution Engine Implementation (C++20)

To truly understand how a database engine executes Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms without hand-waving, examine the C++20 storage kernel operator below. It models how the execution engine iterates over pinned buffer pool pages, evaluates tuple predicates, and tracks page I/O statistics:

C++2032 lines
#include <iostream>
#include <vector>
#include <cstdint>
#include <string>
#include <algorithm>

// Database Engine Kernel Operator: Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms
struct TuplePageStats {
    uint64_t tuples_examined;
    uint64_t tuples_emitted;
    uint64_t pages_pinned;
};

inline TuplePageStats eval_table_statistics_histograms_(const std::vector<int64_t>& keys, int64_t predicate_bound) noexcept {
    TuplePageStats stats{0, 0, (keys.size() + 127) / 128};
    for (int64_t k : keys) {
        ++stats.tuples_examined;
        if (k >= predicate_bound) {
            ++stats.tuples_emitted;
        }
    }
    return stats;
}

int main() {
    std::vector<int64_t> relation = {10, 25, 40, 55, 70, 85, 100, 115};
    auto res = eval_table_statistics_histograms_(relation, 50);
    std::cout << "[Engine Operator: table-statistics-histograms-cardinality] examined=" << res.tuples_examined
              << " emitted=" << res.tuples_emitted
              << " pages=" << res.pages_pinned << "\n";
    return 0;
}

7. Production Failure Modes, Anti-Patterns & Staff Tuning Checklist

Production Pitfall & SEV-1 Outage Pattern

The most common production failure in Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms occurs when a query passes functional unit tests on a 50-row local fixture but degrades into an O(N2)O(N^2) loop, an unindexed full-table scan, or a silent NULL data-drop once table cardinality crosses 10710^7 rows. Always verify both NULL boundary rows and physical buffer reads before deploying to production.

  • Verify Execution Plans Early: Never guess what the planner will do—run EXPLAIN QUERY PLAN (SQLite) or EXPLAIN (ANALYZE, BUFFERS) (PostgreSQL) and confirm that estimated row counts match actual row counts within 2×2\times.
  • Guard Against Three-Valued NULL Traps: Audit every NOT IN, outer-join WHERE filter, and aggregate AVG/COUNT(col) expression for nullable columns; prefer NOT EXISTS and explicit COALESCE defaults.
  • Keep Predicates SARGable: Never wrap an indexed column in a function, arithmetic expression, or implicit type cast on the left-hand side of a comparison operator.
  • Bound Memory & Lock Scope: Ensure sorting, hashing, and batch mutations operate within bounded memory budgets (work_mem) and hold row/table locks for the shortest possible duration.
Check yourself Question 1 of 4
Concept Check Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms — Core Relational Invariant recall

Which statement accurately characterizes the primary mechanism and guarantee of Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms?

Guided SQL & Database Engine Practice · Browser WASM Workbench 3 Guided Steps + Progressive Hints

Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms — Guided SQL & Engine Lab

How ANALYZE samples pages to populate pg_statistic / sqlite_stat1 with Most Common Values (MCV) lists and equi-depth histogram bounds.

⏱ Target Time: O(N) scan / O(log_B N) indexed 💾 Auxiliary Space: O(1) streaming tuple state 🧭 Pattern: The Query Planner, Cost-Based Optimizer & EXPLAIN
01 Phase 1 · Tuple State & Boundaries
Initialize Tuple Scan State (eval_table_statistics_histograms_)
Allocate the operator state structure for Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms and establish zero-row boundary invariants.
Replace TODO (Step 1) inside eval_table_statistics_histograms_ in src/main.cpp by initializing ExecutionResult out{}; and iterating over table.
💡 Progressive Hint (Step 1)
ExecutionResult out{};
for (const auto& row : table) {
  ++out.rows_scanned;
02 Phase 2 · Three-Valued Logic & Predicate Evaluation
Evaluate 3VL NULL Guard & Predicate Filter
In SQL, NULL comparisons evaluate to UNKNOWN and must be excluded before aggregating.
Implement TODO (Step 2) in src/main.cpp to check !row.is_null && row.metric_cents >= min_cents.
💡 Progressive Hint (Step 2)
if (!row.is_null && row.metric_cents >= min_cents) {
  ++out.rows_matched;
  out.sum_cents += row.metric_cents;
}
03 Phase 3 · Aggregate Projection & Verification
Return Projected Tuple Summary & Pass Unit Assertions
Verify exact integer-cent accumulation and row counts across edge cases.
Complete TODO (Step 3) in src/main.cpp by returning out; and clicking Run & Test.
💡 Progressive Hint (Step 3)
return out;

Key Takeaways

Table Statistics (ANALYZE): Null Fraction, NDV, Most Common Values & Histograms (table-statistics-histograms-cardinality): How ANALYZE samples pages to populate pg_statistic / sqlite_stat1 with Most Common Values (MCV) lists and equi-depth histogram bounds.
Always separate logical SQL semantics (FROM -> WHERE -> GROUP BY -> HAVING -> WINDOW -> SELECT -> ORDER BY -> LIMIT) from the physical execution plan chosen by the cost-based optimizer.
Audit every predicate and join condition for Three-Valued Logic (NULL -> UNKNOWN) edge cases and verify SARGability so B+Tree indexes can perform O(log_B N) range seeks.
Use EXPLAIN QUERY PLAN / EXPLAIN (ANALYZE, BUFFERS) to inspect physical scan operators, join algorithms, and temporary sort/hash spills before shipping queries to production.
Was this lesson helpful? Spot an issue or have a suggestion? Let us know on GitHub.
Report an issue