SQL SQL In Depth
0%
lesson percentiles median histograms

Statistical SQL: Equi-Width Histograms, Percentiles & Medians

7 min read Module 2.1: Grouping, Aggregations & Multi-Dimensional Rollups Updated Oct 26, 2026
📄 Cheat Sheet
Statistical SQL: Equi-Width Histograms, Percentiles & Medians — Database Systems & SQL Architecture Lecture
Arpit Bhayani (Asli Engineering) Statistical SQL: Equi-Width Histograms, Percentiles & Medians — Database Systems & SQL Architecture Lecture Watch on YouTube ↗

Builds first-principles mastery of Statistical SQL: Equi-Width Histograms, Percentiles & Medians with concrete query execution trees, storage page layouts, and production tuning trade-offs.

0:00 / 3:58

1. First-Principles Mental Model & Relational Mechanics

Every SQL statement in Statistical SQL: Equi-Width Histograms, Percentiles & Medians compiles down to a deterministic tree of relational algebra operators acting on physical pages in the buffer pool. At the logical layer, Computing exact and approximate p50/p95/p99 latencies, discrete vs continuous percentiles, and bucketed frequency distributions in SQL. 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 histograms-percentiles-medians within Grouping, Aggregations & Multi-Dimensional Rollups, 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 — Statistical SQL: Equi-Width Histograms, Percentiles & Medians

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 Statistical SQL: Equi-Width Histograms, Percentiles & Medians 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 percentiles, and πA\pi_{A} projects the target attribute schema without violating domain constraints.

2. Database Table Schema, Execution Pipeline & Visual Architecture

Tracing how Statistical SQL: Equi-Width Histograms, Percentiles & Medians 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 (percentiles): 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 (median): 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 (histograms): 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.
Statistical SQL: Equi-Width Histograms, Percentiles... — Partitioned Table & Sliding Window Frame Module M04 · PARTITION BY dept_id ORDER BY salary_usd DESC · Frame Overlay (percentiles) TABLE employees (Partitioned Tuple Stream) PK emp_id dept_id name salary_usd RANK / SUM OVER 2 2 (Storage) Vikramaditya $255,000 #1 · $255k 4 2 (Storage) Mateo Silva $215,000 #2 · $470k [CURRENT ROW] 5 2 (Storage) Aisha Patel $198,000 #3 · $668k 3 3 (Planner) Hannah L. $250,000 #1 · $250k (New Partition) WINDOW FRAME INVARIANTS • Preserves all N input tuples • Frame: UNBOUNDED PRECEDING AND CURRENT ROW • Peer ties handled by ROWS vs RANGE vs GROUPS • Evaluated at Step 5 (pre-SELECT)
flowchart LR A["1. FROM / JOIN (percentiles)"] --> B["2. WHERE / 3VL Filter (median)"] B --> C["3. GROUP BY / WINDOW OVER"] C --> D["4. SELECT Projection & ORDER BY (histograms)"]

3. Interactive Table-Level & Storage Engine Simulator

Use the interactive simulator below to step through Statistical SQL: Equi-Width Histograms, Percentiles & Medians at the tuple and page level. Observe how input rows, intermediate filter/join states, NULL badges, and physical page reads evolve at each step:

HashAggregate Bucketing, HAVING vs WHERE & Multi-Dimensional ROLLUP/CUBE
HashAggregate / CUBE

Step through hash-table group bucketing, FILTER (WHERE ...) partial accumulators, and hierarchical GROUPING SETS / ROLLUP subtotal generation.

Step 1 / 7
Custom Input:
Timeline

Invariant & State

Relation initialized with 5 tuples across schema (group_key, grouping_mask, row_count, sum_revenue, p95_latency_ms) — preset: GROUP BY ROLLUP (region, tier) with GROUPING() Bitmask.
🔗 Live Pointer & State Transition Graph — HashAggregate Bucketing, HAVING vs WHERE & Multi-Dimensional ROLLUP/CUBE Active Pointer Jump/Transition Matched/Optimal
Tuple # (us-e… [0] (us-e… [1] (us-e… [2] (eu-w… [3] (NULL… [4]
📋 HashAggregate Bucketing, HAVING vs WHERE & Multi-Dimensional ROLLUP/CUBE — Initial Relation State 5 row(s)
group_keygrouping_maskrow_countsum_revenuep95_latency_msState
(us-east, enterprise)0b00 (Detail)42128,400</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">18ms</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:10.5px;font-weight:700;font-family:var(--font-mono,monospace);color:#3b82f6;">CURSOR START</td></tr><tr style="background:transparent;border-left:3px solid transparent;"><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">(us-east, pro)</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">0b00 (Detail)</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">95</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">47,50022ms
(us-east, NULL)0b01 (Region Subtotal)137175,900</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">21ms</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);"></td></tr><tr style="background:transparent;border-left:3px solid transparent;"><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">(eu-west, enterprise)</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">0b00 (Detail)</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">31</td><td style="padding:5px 8px;border-bottom:1px solid var(--border-subtle,#1f1f23);font-size:11.5px;font-family:var(--font-mono,monospace);">94,20024ms
(NULL, NULL)0b11 (Grand Total)168$270,10022ms
[0](us-east, enterprise):42Tuple #0
[1](us-east, pro):95
[2](us-east, NULL):137
[3](eu-west, enterprise):31
[4](NULL, NULL):168
Input Tuples
5
Columns
5
Preset Mode
rollup
Pipeline Stage
1. Initial Scan
[Step 1] Initialized HashAggregate Bucketing, HAVING vs WHERE & Multi-Dimensional ROLLUP/CUBE (GROUP BY ROLLUP (region, tier) with GROUPING() Bitmask) with 5 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: org_hr | Department Budget Utilization & Headcount Aggregation
SELECT
  d.dept_id,
  d.name AS department_name,
  d.cost_center,
  COUNT(e.emp_id) AS headcount,
  SUM(e.salary_usd) AS active_payroll_usd,
  d.annual_budget_usd,
  ROUND((SUM(e.salary_usd) * 100.0) / d.annual_budget_usd, 1) AS budget_used_pct
FROM departments AS d
LEFT JOIN employees AS e
  ON e.dept_id = d.dept_id
GROUP BY d.dept_id, d.name, d.cost_center, d.annual_budget_usd
HAVING COUNT(e.emp_id) >= 1
ORDER BY active_payroll_usd DESC;

5. Cross-Engine Dialect & Cost Comparison Matrix

While the SQL ISO standard defines the logical behavior of Statistical SQL: Equi-Width Histograms, Percentiles & Medians, 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 Statistical SQL: Equi-Width Histograms, Percentiles & Medians
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 Statistical SQL: Equi-Width Histograms, Percentiles & Medians 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: Statistical SQL: Equi-Width Histograms, Percentiles & Medians
struct TuplePageStats {
    uint64_t tuples_examined;
    uint64_t tuples_emitted;
    uint64_t pages_pinned;
};

inline TuplePageStats eval_histograms_percentiles_media(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_histograms_percentiles_media(relation, 50);
    std::cout << "[Engine Operator: histograms-percentiles-medians] 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 Statistical SQL: Equi-Width Histograms, Percentiles & Medians 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 Statistical SQL: Equi-Width Histograms, Percentiles & Medians — Core Relational Invariant recall

Which statement accurately characterizes the primary mechanism and guarantee of Statistical SQL: Equi-Width Histograms, Percentiles & Medians?

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

Statistical SQL: Equi-Width Histograms, Percentiles & Medians — Guided SQL & Engine Lab

Computing exact and approximate p50/p95/p99 latencies, discrete vs continuous percentiles, and bucketed frequency distributions in SQL.

⏱ Target Time: O(N) scan / O(log_B N) indexed 💾 Auxiliary Space: O(1) streaming tuple state 🧭 Pattern: Grouping, Aggregations & Multi-Dimensional Rollups
01 Phase 1 · Tuple State & Boundaries
Initialize Tuple Scan State (eval_histograms_percentiles_media)
Allocate the operator state structure for Statistical SQL: Equi-Width Histograms, Percentiles & Medians and establish zero-row boundary invariants.
Replace TODO (Step 1) inside eval_histograms_percentiles_media 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

Statistical SQL: Equi-Width Histograms, Percentiles & Medians (histograms-percentiles-medians): Computing exact and approximate p50/p95/p99 latencies, discrete vs continuous percentiles, and bucketed frequency distributions in SQL.
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