SQL SQL In Depth
0%
build build columnar zone-maps

Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown

7 min read Module 6.1: Columnar Storage, Vectorized OLAP & Modern Lakehouses Updated Oct 26, 2026
📄 Cheat Sheet
Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown — Database Systems & SQL Architecture Lecture
CMU Database Group (Andy Pavlo) Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown — Database Systems & SQL Architecture Lecture Watch on YouTube ↗

Builds first-principles mastery of Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown with concrete query execution trees, storage page layouts, and production tuning trade-offs.

0:00 / 5:11

1. First-Principles Mental Model & Relational Mechanics

Every SQL statement in Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown compiles down to a deterministic tree of relational algebra operators acting on physical pages in the buffer pool. At the logical layer, Build a columnar storage engine that compresses column chunks with Dictionary and Run-Length Encoding and prunes blocks via Zone Map min/max metadata. 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 build-columnar-compression-query-engine within Columnar Storage, Vectorized OLAP & Modern Lakehouses, 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 — Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown

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 Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown 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 build, and πA\pi_{A} projects the target attribute schema without violating domain constraints.

2. Database Table Schema, Execution Pipeline & Visual Architecture

Tracing how Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown 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 (build): 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 (columnar): 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 (zone-maps): 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.
Hands-On Build: Columnar RLE/Dictionary Encoder wit... — 8KB Slotted Page & MVCC Tuple Versioning Module M16 · PageHeader (pd_lsn) · Line Pointer Array (ItemId) · MVCC Tuple (xmin / xmax) 8192-BYTE SLOTTED PAGE · pd_lsn=0/1A8F40 · pd_lower=44 · pd_upper=7820 lp[1] -> 8096 lp[2] -> 7960 lp[3] -> 7820 ──► pd_lower UNALLOCATED FREE SPACE (7776 bytes) Tuple v1 (ctid 0,1): xmin=501 xmax=509 [DEAD] | acct=101 | bal=475000 Tuple v2 (ctid 0,2): xmin=509 xmax=0 [LIVE] | acct=101 | bal=415000 MVCC SNAPSHOT & WAL INVARIANT • Snapshot xmin=505, xmax=512 • Readers never block Writers • WAL Rule: Flush LSN >= pd_lsn before dirty page eviction • VACUUM reclaims dead v1 tuple when OldestXmin > 509
flowchart LR A["1. FROM / JOIN (build)"] --> B["2. WHERE / 3VL Filter (columnar)"] B --> C["3. GROUP BY / WINDOW OVER"] C --> D["4. SELECT Projection & ORDER BY (zone-maps)"]

3. Interactive Table-Level & Storage Engine Simulator

Use the interactive simulator below to step through Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown at the tuple and page level. Observe how input rows, intermediate filter/join states, NULL badges, and physical page reads evolve at each step:

Columnar Storage (Parquet Row Groups), RLE/Dictionary Encoding & Zone Map Pruning
Columnar / Zone Maps

Compare NSM row pages against DSM columnar chunks. Watch Zone Map (min/max) metadata skip 90% of row groups and evaluate predicates directly on Dictionary/RLE codes.

Step 1 / 6
Custom Input:
Timeline

Invariant & State

Relation initialized with 4 tuples across schema (row_group_id, rows_count, zone_min_ts, zone_max_ts, encoding, scan_decision) — preset: Zone Map Min/Max Row-Group Pruning on WHERE ts >= 2026-03-01.
🧭 Live Hash Ring & Bucket Probe Telemetry — Columnar Storage (Parquet Row Groups), RLE/Dictionary Encoding & Zone Map Pruning Probe Collision/Swap Hit/Placed
RowG… RowG… RowG… RowG… B[0] RowGroup #0:2026-01-01 (Tuple #0) B[1] RowGroup #1:2026-02-01 B[2] RowGroup #2:2026-03-01 B[3] RowGroup #3:2026-03-16
📋 Columnar Storage (Parquet Row Groups), RLE/Dictionary Encoding & Zone Map Pruning — Initial Relation State 4 row(s)
row_group_idrows_countzone_min_tszone_max_tsencodingscan_decisionState
RowGroup #065,5362026-01-012026-01-31Dict + RLE (3.1×)PRUNED BY ZONE MAP (max < target)CURSOR START
RowGroup #165,5362026-02-012026-02-28Dict + RLE (3.4×)PRUNED BY ZONE MAP (max < target)
RowGroup #265,5362026-03-012026-03-15Dict + RLE (3.2×)SCANNED via SIMD Selection Vector ✓
RowGroup #365,5362026-03-162026-03-31Dict + RLE (3.5×)SCANNED via SIMD Selection Vector ✓
[0]RowGroup #0:2026-01-01Tuple #0
[1]RowGroup #1:2026-02-01
[2]RowGroup #2:2026-03-01
[3]RowGroup #3:2026-03-16
Input Tuples
4
Columns
6
Preset Mode
zonemap
Pipeline Stage
1. Initial Scan
[Step 1] Initialized Columnar Storage (Parquet Row Groups), RLE/Dictionary Encoding & Zone Map Pruning (Zone Map Min/Max Row-Group Pruning on WHERE ts >= 2026-03-01) 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 · WASM13 lines
-- Dataset: saas_telemetry | Analytical Telemetry Aggregation & Event Latency Profile
SELECT
  u.plan_tier,
  e.event_type,
  COUNT(*) AS event_count,
  ROUND(AVG(e.latency_ms), 2) AS avg_latency_ms,
  MAX(e.latency_ms) AS max_latency_ms,
  MIN(e.latency_ms) AS min_latency_ms
FROM user_events AS e
INNER JOIN saas_users AS u
  ON u.user_id = e.user_id
GROUP BY u.plan_tier, e.event_type
ORDER BY event_count DESC, avg_latency_ms DESC;

5. Cross-Engine Dialect & Cost Comparison Matrix

While the SQL ISO standard defines the logical behavior of Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown, 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 Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown
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 Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown 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: Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown
struct TuplePageStats {
    uint64_t tuples_examined;
    uint64_t tuples_emitted;
    uint64_t pages_pinned;
};

inline TuplePageStats eval_build_columnar_compression_q(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_build_columnar_compression_q(relation, 50);
    std::cout << "[Engine Operator: build-columnar-compression-query-engine] 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 Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown 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 Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown — Core Relational Invariant recall

Which statement accurately characterizes the primary mechanism and guarantee of Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown?

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

Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown — Guided SQL & Engine Lab

Build a columnar storage engine that compresses column chunks with Dictionary and Run-Length Encoding and prunes blocks via Zone Map min/max metadata.

⏱ Target Time: O(N) scan / O(log_B N) indexed 💾 Auxiliary Space: O(1) streaming tuple state 🧭 Pattern: Columnar Storage, Vectorized OLAP & Modern Lakehouses
01 Phase 1 · Tuple State & Boundaries
Initialize Tuple Scan State (eval_build_columnar_compression_q)
Allocate the operator state structure for Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown and establish zero-row boundary invariants.
Replace TODO (Step 1) inside eval_build_columnar_compression_q 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

Hands-On Build: Columnar RLE/Dictionary Encoder with Zone-Map Predicate Pushdown (build-columnar-compression-query-engine): Build a columnar storage engine that compresses column chunks with Dictionary and Run-Length Encoding and prunes blocks via Zone Map min/max metadata.
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