Section 1: Recap

Approximate Sketches (SIGMOD'24)

SELECT COUNT(*) FROM customers c JOIN orders o ON c.customer_id = o.customer_id
	WHERE c.age = 35 AND c.city = 'SF'

the background

The Independence Assumption

Traditional estimators assume columns are independent

This assumption fails → Massive estimation errors

Traditional Approaches & Their Limitations

The Tug-of-War Metaphor

AGMS Sketch: Elements compete in a "tug-of-war"

Each color assigned to +1 or -1 team

Pairwise Independent Hashing

Hash function: $\xi: \mathbb{R} \rightarrow \{\pm 1\}$

AGMS Variance for frequency $f_j$

AGMS has high variance...

so you need to play a lot of tug-of-war!

Fast-AGMS: The Speed-Up

Use width-$w$ array instead of single counter

Each element goes to ONE counter → 1/w update time!

Range Queries: Dyadic Intervals

How to handle range predicates?

Decompose range into dyadic intervals!

Any range decomposes into ≤ $2(\log_2(b-a) - 1)$ intervals

Join Cardinality Estimation

For join $X \bowtie Y$:

$|X \bowtie Y| \approx S_X \cdot S_Y$

Dot product of sketch vectors!

$T_1 \bowtie T_2 \bowtie T_3$

This generalizes to sktech tensors for more joins

But tensor size grows exponentially...

Efficient Multiway Joins: FFT

Avoiding Tensors with Circular Convolution

• Tensor size grows exponentially ($N^{\text{cols}}$)
• Convolution theorem: $A * B = \mathcal{F}^{-1}(\mathcal{F}(A) \cdot \mathcal{F}(B))$
• Compute in $O(N \log N)$ using Fast Fourier Transform!

Section 4: Other Sketches

Count-Min Sketch

Simplified: Always increment (no $\xi$ hash)

Trade-off: Biased (overestimates), but simpler & faster

Bound Sketch: Tighter Bounds

Track maximum frequency per bucket

$\max_i f_i \leq \sum_i f_i$ → Tighter than Count-Min!

Sketch Properties Summary

d = # independent sketches, w = sketch width

The Problem with Sketches

Solution: Approximate Sketches

Idea: Use ML models to generate sketches on-demand

No data scan required! ✨

Three Approaches to the Problem

Three Approaches to the Problem

Probabilities into Sketches

Idea: Train a model to estimate p for ANY predicate φ

Probabilities into Sketches

For a hash function h : ℝ → {1, ..., w}:

The i-th counter in the sketch:

Therefore: sketch = p × |σ_φ(T)|

Transformer Architecture

SELECT COUNT(*) FROM customers c JOIN orders o ON c.customer_id = o.customer_id
WHERE c.age = 35 AND c.city = 'SF'

Why Bidirectional Transformers?

Essential for approximating sketches with arbitrary filter conditions

Training Data: Raw Table

Start with actual database table rows

Goal: Transform this data to train BERT to predict sketches for any filter condition

Training Pipeline

Join Cardinality Estimation Process

For query: SELECT * FROM A JOIN B ON A.x = B.y WHERE ...

1. Approximate Sketches:
   • Model for A: infer sketch(σ_φ(A).x)
   • Model for B: infer sketch(σ_ψ(B).y)
2. Estimate Join:
   • |A ⋈ B| ≈ sketch(A) · sketch(B)
   • Take median of d independent estimates

Experimental Setup

Datasets:

• IMDb — 6 tables, 20 columns, up to 36M rows
• JOB-light: 70 queries
• JOB-light-ranges: 1000 queries

Metrics

• Q-error: multiplicative error between estimated and true cardinality
• P-error: multiplicative error between plan cost of estimated and best plan

Q-error by Sketch Width

Estimation Time

Approx. faster than exact (pushdown) sketches!

Q-error & P-error

Runtime

What are Sum-Product Networks?

Trees made of:

• Sum nodes: Mixture of distributions (weighted average)
• Product nodes: Factorization of independent distributions
• Leaves: Simple univariate distributions
• Root: Represents full joint distribution

What are Sum-Product Networks?

Training left, inference right

Training

• One random variable
  → terminate (leaf node)
• Independent variables
  → factorize (product node)
• Otherwise
  → cluster (sum node)

Inference

Query for
the distribution of $P(X, Z)$ where $X=x_2$

Sketches from SPNs

Sketches from SPNs

Experimental Results

Experimental Setup

Datasets:

• JOB-light: 70 queries (696 subqueries) on 6 IMDb tables
  • Transitive joins, star schema, up to 5 tables
• Stats-CEB: 146 queries (2603 subqueries) on 8 Stack Exchange tables
  • Non-transitive joins, more skewed/correlated data

Sketch Approximation Error

Takeaway: Just cluster, even a little bit, to drastically reduce error!

Approximation Efficiency

Within 3% of exact sketches! But much faster to compute.

Training Time Comparison

*GPU required; others CPU-only

Sketched SPNs competitive with other per-relation methods

Model Complexity Trade-off

Query Execution Time

Exact F-AGMS would be the fastest, if not for construction time!

Model Comparison on JOB-light

Contributions Summary

Novel Contributions

Impact on Query Optimization