joaoh82
diff --git a/‎benchmarks/README.md‎
Lines changed: 46 additions & 3 deletions b/‎benchmarks/README.md‎
Lines changed: 46 additions & 3 deletions
diff --git a/‎benchmarks/benches/suite.rs‎
Lines changed: 107 additions & 2 deletions b/‎benchmarks/benches/suite.rs‎
Lines changed: 107 additions & 2 deletions
diff --git a/‎benchmarks/src/data.rs‎
Lines changed: 148 additions & 0 deletions b/‎benchmarks/src/data.rs‎
Lines changed: 148 additions & 0 deletions
@@ -2,7 +2,7 @@
 
 Benchmark suite for SQLRite vs SQLite (and friends). Tracks task **SQLR-4** / **SQLR-16**.
 
-> **Status (2026-05-06):** sub-phases 9.1 + 9.2 landed — harness + Group A (W1–W6). W7–W12 land in 9.3–9.4. The first official pinned-host JSON gets committed in 9.6. See [`docs/benchmarks-plan.md`](../docs/benchmarks-plan.md) for the canonical design + the resolved Q1–Q8 decisions.
+> **Status (2026-05-07):** sub-phases 9.1 + 9.2 + 9.3 landed — harness + Group A (W1–W6) + Group B (W7–W9). W10–W12 land in 9.4. The first official pinned-host JSON gets committed in 9.6. See [`docs/benchmarks-plan.md`](../docs/benchmarks-plan.md) for the canonical design + the resolved Q1–Q8 decisions.
 
 ## Quick start
 
@@ -27,7 +27,7 @@ Three drivers, in plan order:
 Three groups (full descriptions in [`docs/benchmarks-plan.md`](../docs/benchmarks-plan.md#workloads)):
 
 - **Group A — OLTP baseline.** W1 read-by-PK, W2 range scan, W3 bulk insert, W4 single-row insert, W5 mixed OLTP, W6 index lookup. ✅ shipped (9.1 + 9.2).
-- **Group B — SQL-feature scaling.** W7 aggregate, W8 GROUP BY, W9 INNER JOIN. Lands in 9.3.
+- **Group B — SQL-feature scaling.** W7 aggregate, W8 GROUP BY, W9 INNER JOIN. ✅ shipped (9.3).
 - **Group C — Differentiators.** W10 vector top-10, W11 BM25 top-10, W12 hybrid retrieval. Lands in 9.4.
 
 Workloads are versioned (`W1.v1`, `W1.v2`, …) per Q8 — bumping the version is the explicit "I changed the benchmark" gesture.
@@ -124,6 +124,46 @@ Unique-index probes — every probe matches exactly one row. SQLRite's optimizer
 
 **Read this as:** secondary-index path is healthy — same ~5–8× per-iter-parse-cost band as W1. The index probe itself is fine; what we're measuring is mostly `sqlparser` per call.
 
+### W7 — `SELECT SUM(v) FROM big` (1M-row full-scan aggregate)
+
+Single-statement aggregate. No WHERE, no GROUP BY. Both engines walk every row through their executor; the question is how cheap the per-row "touch" is.
+
+| Engine | Median per SUM | Throughput (rows/s) |
+|---|---|---|
+| SQLRite | ~111 ms | ~9.0M |
+| SQLite (rusqlite, WAL+NORMAL) | ~31 ms | ~32M |
+| **Ratio** | **~3.5×** | |
+
+**Read this as:** healthy. The full-scan aggregator is the closest "engine throughput" measurement we have — no parse cache miss to amortize, just per-row work. Closer to SQLite than W1 (~8×) suggests the per-row machinery is tighter than the per-iter parse path. Encouraging; says the executor isn't broadly slow.
+
+### W8 — `SELECT k, COUNT(*) FROM big GROUP BY k` (three cardinalities)
+
+1M-row table, GROUP BY at 10 / 1k / 100k distinct keys.
+
+| Cardinality | SQLRite | SQLite (rusqlite, WAL+NORMAL) | Notes |
+|---|---|---|---|
+| 10 groups | ~204 ms | ~460 ms | SQLRite faster — likely SQLite's planner picks a sort-then-group path here (small group counts often slower than a hash). Not the headline; small samples. |
+| 1,000 groups | ~1.50 s | ~242 ms | ~6.2× |
+| 100,000 groups | **skipped** | ~241 ms | SQLRite skipped by default — see note below |
+
+**SQLRite × 100k-cardinality is skipped by default** in `make bench`. A first measurement clocked ~245 s/iter (~41 min for 10 samples), strongly suggesting an O(n × cardinality) path inside the GROUP BY executor (a hash aggregator should be O(n + groups)). **SQLR-19** tracks the investigation. Set `SQLRITE_BENCH_W8_CARD_100K_SQLRITE=1` once that lands to re-include the bucket.
+
+**Read this as:** GROUP BY at low cardinality is fine; high-cardinality work is broken. The fix is probably a `Vec`-backed group store → `HashMap`-backed.
+
+### W9 — INNER JOIN, customer ↔ order, probe by customer PK
+
+Plan target was two **100k-row tables**. v1 ships at **10k rows** because SQLRite's join executor doesn't push the ON predicate down to an index probe on the inner side — at the 100k scale, per-iter cost was >5 minutes (88 minutes of measured runtime didn't produce a single sample before the smoke run was killed). **SQLR-20** tracks the join-planner / inner-side index-probe fix. Until then, v1 = 10k rows; bumping to 100k follows the fix + a `W9.v2` tag.
+
+Even at 10k scale, the gap is large:
+
+| Engine | Median per probe | Throughput (probes/s) |
+|---|---|---|
+| SQLRite | ~32 s | ~0.03 |
+| SQLite (rusqlite, WAL+NORMAL) | ~2.3 µs | ~459k |
+| **Ratio** | **~14,000,000×** ⚠️ | |
+
+**Read this as:** SQLRite's join executor scans the entire inner table per outer row (no index probe pushdown), and the per-pair overhead is much higher than a single-table full scan. At 32 s for ~10k inner-row checks, the per-row cost is ~3 ms — about **3,000× slower** than W2's full-scan rate (1 µs/row). The inner-side index probe is the obvious next unlock; the per-pair overhead is the second.
+
 ## Adding a workload
 
 Per the [`docs/benchmarks-plan.md`](../docs/benchmarks-plan.md#sub-phases) sequencing:
@@ -165,7 +205,10 @@ benchmarks/
 │   │   ├── bulk_insert.rs   — W3 bulk insert (100k/txn)
 │   │   ├── single_insert.rs — W4 single-row insert
 │   │   ├── mixed_oltp.rs    — W5 50/50 SELECT+UPDATE
-│   │   └── index_lookup.rs  — W6 secondary-index lookup
+│   │   ├── index_lookup.rs  — W6 secondary-index lookup
+│   │   ├── aggregate.rs     — W7 SUM(v) over 1M rows
+│   │   ├── group_by.rs      — W8 GROUP BY (10/1k/100k cardinalities)
+│   │   └── join.rs          — W9 INNER JOIN, customer ↔ order
 │   └── bin/
 │       └── aggregate.rs   — walks target/criterion/ → results/*.json
 ├── benches/
 
@@ -29,8 +29,8 @@ use sqlrite_benchmarks::Driver;
 use sqlrite_benchmarks::drivers::sqlite::SQLiteDriver;
 use sqlrite_benchmarks::drivers::sqlrite::SQLRiteDriver;
 use sqlrite_benchmarks::workloads::{
-    bulk_insert as w3, index_lookup as w6, kv as w1, mixed_oltp as w5, range_scan as w2,
-    single_insert as w4,
+    aggregate as w7, bulk_insert as w3, group_by as w8, index_lookup as w6, join as w9, kv as w1,
+    mixed_oltp as w5, range_scan as w2, single_insert as w4,
 };
 
 /// Pick a DB filename inside `dir` based on the driver — keeps a
@@ -276,6 +276,105 @@ fn register_w6<D: Driver>(c: &mut Criterion, driver: D) {
     drop(tmp);
 }
 
+// ---------------------------------------------------------------------------
+// W7 — SUM aggregate over 1M rows
+// ---------------------------------------------------------------------------
+
+fn register_w7<D: Driver>(c: &mut Criterion, driver: D) {
+    let tmp = tempdir_for("w7", driver.name());
+    let path = db_path(tmp.path(), driver.name(), "w7");
+    let (mut conn, dataset) = w7::setup(&driver, &path).expect("W7 setup");
+    w7::correctness_check(&driver, &mut conn, &dataset).expect("W7 correctness check");
+
+    let mut group = c.benchmark_group(w7::W7.full());
+    // SUM over 1M rows is single-shot heavy work — drop sample size
+    // so a smoke run finishes in a couple of minutes per driver.
+    group.sample_size(10);
+    let bench_id = format!("{}/default", driver.name());
+    group.bench_function(&bench_id, |b| {
+        b.iter(|| {
+            let n = w7::bench_iter(&driver, &mut conn).expect("W7 SUM");
+            black_box(n)
+        });
+    });
+    group.finish();
+    drop(conn);
+    drop(tmp);
+}
+
+// ---------------------------------------------------------------------------
+// W8 — GROUP BY at three cardinalities (10 / 1k / 100k groups)
+// ---------------------------------------------------------------------------
+
+fn register_w8<D: Driver>(c: &mut Criterion, driver: D) {
+    let tmp = tempdir_for("w8", driver.name());
+    let path = db_path(tmp.path(), driver.name(), "w8");
+    let (mut conn, _dataset) = w8::setup(&driver, &path).expect("W8 setup");
+    w8::correctness_check(&driver, &mut conn).expect("W8 correctness check");
+
+    for &(label, bucket, _expected) in &w8::BUCKETS {
+        // SQLRite's GROUP BY at 100k-cardinality over 1M rows is
+        // pathologically slow today (~245 s per iter on an M-series
+        // MBP — see SQLR-19 for the investigation follow-up). That
+        // would block a smoke run for ~40 min, so we skip the cell
+        // by default. Set `SQLRITE_BENCH_W8_CARD_100K_SQLRITE=1` to
+        // force-include it once the blowup is resolved.
+        if label == "card-100k"
+            && driver.name() == "sqlrite"
+            && std::env::var("SQLRITE_BENCH_W8_CARD_100K_SQLRITE")
+                .ok()
+                .as_deref()
+                != Some("1")
+        {
+            continue;
+        }
+        let group_name = format!("{}/{}", w8::W8.full(), label);
+        let mut group = c.benchmark_group(&group_name);
+        group.sample_size(10);
+        let bench_id = format!("{}/default", driver.name());
+        group.bench_function(&bench_id, |b| {
+            b.iter(|| {
+                let n = w8::bench_iter(&driver, &mut conn, bucket).expect("W8 GROUP BY");
+                black_box(n)
+            });
+        });
+        group.finish();
+    }
+    drop(conn);
+    drop(tmp);
+}
+
+// ---------------------------------------------------------------------------
+// W9 — INNER JOIN, customer ↔ order, probe by customer PK
+// ---------------------------------------------------------------------------
+
+fn register_w9<D: Driver>(c: &mut Criterion, driver: D) {
+    let tmp = tempdir_for("w9", driver.name());
+    let path = db_path(tmp.path(), driver.name(), "w9");
+    let (mut conn, dataset) = w9::setup(&driver, &path).expect("W9 setup");
+    w9::correctness_check(&driver, &mut conn, &dataset).expect("W9 correctness check");
+
+    let mut group = c.benchmark_group(w9::W9.full());
+    // SQLRite's nested-loop join + un-indexed inner scan is heavy
+    // (~100k rows scanned per probe). Cap the sample size so a
+    // smoke run finishes; override at the CLI for a sharper estimate.
+    group.sample_size(10);
+    let bench_id = format!("{}/default", driver.name());
+    let probes = dataset.probes.clone();
+    let mut idx = 0usize;
+    group.bench_function(&bench_id, |b| {
+        b.iter(|| {
+            let cid = probes[idx % probes.len()];
+            idx = idx.wrapping_add(1);
+            let row = w9::bench_iter(&driver, &mut conn, cid).expect("W9 JOIN");
+            black_box(row)
+        });
+    });
+    group.finish();
+    drop(conn);
+    drop(tmp);
+}
+
 // ---------------------------------------------------------------------------
 // Entry point
 // ---------------------------------------------------------------------------
@@ -293,6 +392,12 @@ fn benches(c: &mut Criterion) {
     register_w5(c, SQLiteDriver);
     register_w6(c, SQLRiteDriver);
     register_w6(c, SQLiteDriver);
+    register_w7(c, SQLRiteDriver);
+    register_w7(c, SQLiteDriver);
+    register_w8(c, SQLRiteDriver);
+    register_w8(c, SQLiteDriver);
+    register_w9(c, SQLRiteDriver);
+    register_w9(c, SQLiteDriver);
 }
 
 criterion_group!(suite, benches);
 
@@ -194,6 +194,154 @@ fn build_range_probes(rng: &mut ChaCha8Rng, width: i64) -> Vec<(i64, i64)> {
     out
 }
 
+/// Dataset for the Group-B "SQL-feature scaling" workloads — W7
+/// (SUM aggregate) and W8 (GROUP BY at three cardinalities).
+///
+/// Schema:
+///
+/// ```sql
+/// CREATE TABLE big (
+///   id     INTEGER PRIMARY KEY,
+///   v      INTEGER,
+///   k_10   INTEGER,
+///   k_1k   INTEGER,
+///   k_100k INTEGER
+/// );
+/// ```
+///
+/// - `v = (id * 7) mod 1000` — varied non-monotone integer for SUM.
+/// - `k_10 = id mod 10` — 10 distinct groups (W8 low-cardinality).
+/// - `k_1k = id mod 1000` — 1k distinct groups.
+/// - `k_100k = id mod 100_000` — 100k distinct groups (essentially
+///   one group per ~10 rows on a 1M-row table; the high-cardinality
+///   stress-test for the hash aggregator).
+///
+/// 1M rows is the plan's W7 target — the largest single-table dataset
+/// in the suite. 1M × ~40 bytes/row ≈ 40 MB on disk; well within
+/// SQLRite's whole-DB-in-RAM model on a 32 GiB host.
+pub struct GroupBDataset {
+    pub rows: Vec<GroupBRow>,
+    /// Pre-computed `SUM(v)` so the W7 correctness gate doesn't have
+    /// to re-derive it on every probe.
+    pub sum_v: i64,
+}
+
+pub struct GroupBRow {
+    pub id: i64,
+    pub v: i64,
+    pub k_10: i64,
+    pub k_1k: i64,
+    pub k_100k: i64,
+}
+
+/// 1M rows. Plan target for W7. W8 reuses the same dataset.
+pub const GROUP_B_ROW_COUNT: usize = 1_000_000;
+
+const GROUP_B_SEED: u64 = 44;
+
+pub fn group_b_dataset() -> GroupBDataset {
+    // Seed kept for forward-compat — the dataset is currently fully
+    // deterministic from `id`, but a future variant may shuffle `v`
+    // independently and we want the seed surface ready.
+    let _rng = ChaCha8Rng::seed_from_u64(GROUP_B_SEED);
+
+    let mut rows = Vec::with_capacity(GROUP_B_ROW_COUNT);
+    let mut sum_v: i64 = 0;
+    for i in 1..=GROUP_B_ROW_COUNT as i64 {
+        let v = (i.wrapping_mul(7)).rem_euclid(1_000);
+        sum_v += v;
+        rows.push(GroupBRow {
+            id: i,
+            v,
+            k_10: i.rem_euclid(10),
+            k_1k: i.rem_euclid(1_000),
+            k_100k: i.rem_euclid(100_000),
+        });
+    }
+    GroupBDataset { rows, sum_v }
+}
+
+/// W9 INNER JOIN dataset. Two 100k-row tables with a 1:1 PK/FK
+/// relationship — every customer has exactly one order. The hot loop
+/// probes by customer PK and joins to the matching order.
+///
+/// Schema:
+///
+/// ```sql
+/// CREATE TABLE customers (id INTEGER PRIMARY KEY, name TEXT);
+/// CREATE TABLE orders (id INTEGER PRIMARY KEY, customer_id INTEGER, amount INTEGER);
+/// CREATE INDEX idx_orders_customer ON orders(customer_id);
+/// ```
+///
+/// SQLRite's join is a nested-loop driver without an inner-side index
+/// probe (see [`docs/supported-sql.md`](../../docs/supported-sql.md)
+/// "JOIN semantics" / `executor.rs::execute_select_rows_joined`). So
+/// per-PK-probe joins should show a meaningful gap vs SQLite's
+/// indexed-nested-loop join. That gap is informational — the plan
+/// flags it as the most useful "what does the join planner cost us?"
+/// number.
+pub struct JoinDataset {
+    pub customers: Vec<JoinCustomer>,
+    pub orders: Vec<JoinOrder>,
+    /// Random customer-PK probes for the bench hot loop.
+    pub probes: Vec<i64>,
+}
+
+pub struct JoinCustomer {
+    pub id: i64,
+    pub name: String,
+}
+
+pub struct JoinOrder {
+    pub id: i64,
+    pub customer_id: i64,
+    pub amount: i64,
+}
+
+/// Plan-deviation note (W9): the plan spec calls for "two 100k-row
+/// tables." A first smoke at that scale measured SQLRite at >5
+/// minutes per iteration on the criterion hot loop — the engine's
+/// join executor is a left-folded nested-loop driver that doesn't
+/// push the ON predicate down to an index probe on the inner side
+/// (`src/sql/executor.rs::execute_select_rows_joined`), so each
+/// per-PK probe scans the full 100k-row inner table. That scale is
+/// untenable for `make bench`.
+///
+/// v1 ships at **10k rows** instead. SQLRite still scans the whole
+/// inner side per probe — the per-probe cost is ~10× lower at this
+/// scale, the gap vs SQLite's indexed nested-loop join stays
+/// meaningful, and the bench finishes in seconds. Bumping back to
+/// 100k follows a SQLRite join-planner / indexed-inner-side
+/// improvement (tracked separately) and a `W9.v2` tag.
+pub const JOIN_ROW_COUNT: usize = 10_000;
+pub const JOIN_PROBE_COUNT: usize = 1_000;
+const JOIN_SEED: u64 = 45;
+
+pub fn join_dataset() -> JoinDataset {
+    let mut rng = ChaCha8Rng::seed_from_u64(JOIN_SEED);
+    let mut customers = Vec::with_capacity(JOIN_ROW_COUNT);
+    let mut orders = Vec::with_capacity(JOIN_ROW_COUNT);
+    for i in 1..=JOIN_ROW_COUNT as i64 {
+        customers.push(JoinCustomer {
+            id: i,
+            name: format!("customer_{i}"),
+        });
+        orders.push(JoinOrder {
+            id: i,
+            customer_id: i,
+            amount: i.rem_euclid(10_000),
+        });
+    }
+    let mut probes: Vec<i64> = (1..=JOIN_ROW_COUNT as i64).collect();
+    probes.shuffle(&mut rng);
+    probes.truncate(JOIN_PROBE_COUNT);
+    JoinDataset {
+        customers,
+        orders,
+        probes,
+    }
+}
+
 /// W4 single-row-insert dataset. The bench loop generates rows on the
 /// fly with monotonically-increasing PKs starting at this base, so the
 /// preload (rows `1..=BASE-1`) sets a stable table size before timing