feat(eqp): emit the GROUP BY/DISTINCT temp-b-tree over a rowid range seek (B9d subset)

The `USE TEMP B-TREE FOR GROUP BY` / `FOR DISTINCT` node now also materializes
over an unambiguous rowid range seek (`WHERE a>? GROUP BY c` →
`SEARCH t USING INTEGER PRIMARY KEY (rowid>?)#USE TEMP B-TREE FOR GROUP BY`), not
just a bare SCAN. The rowid is the table's own clustered key, so there is no
secondary-index choice and thus no cost-model divergence, and the seek returns
rows in rowid order — never the group/distinct-key order — so the b-tree is
always needed. Gated on a rowid *range* seek line (an equality seek is a single
row and stays excluded), reusing group_distinct_btree's existing
secondary-index-leads guard.

The secondary-index-seek variant, and all single-table index *choice* (B9h) and
non-default-collation index selection (B9j), are deferred by design: they depend
on SQLite's stat4-less cost model, which the pinned oracle makes
un-differential-testable (same class as B1b/B4). Documented precisely in
ROADMAP.md and the planner-index-seeks memory.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Author: MagicalTux

ROADMAP.md

@@ -1204,10 +1204,19 @@ tie/representative order), so they are perf/EQP-fidelity work, not correctness:
   over a `LIMIT` body still declines — SQLite full-sorts the materialized `LIMIT` rows,
   whereas pushing the ORDER BY down would render a partial `LAST TERM` index walk when
   the leading prefix is indexed. Boundary rules in the `eqp-derived-coroutine` memory.
-- **B9d — `SEARCH` + `GROUP BY`/`DISTINCT` temp-b-tree node.** graphite emits the
-  grouping b-tree only over a bare `SCAN`; under a `WHERE` seek it omits the node.
-  Entangled with B9h (SQLite often picks a *different* index whose walk serves the
-  grouping), so it should land together with the index-choice work.
+- **B9d — `SEARCH` + `GROUP BY`/`DISTINCT` temp-b-tree node. ◐ Unambiguous subset
+  done.** The grouping b-tree now also materializes over a **rowid *range* seek**
+  (`WHERE a>? GROUP BY c` → `SEARCH t USING INTEGER PRIMARY KEY (rowid>?)#USE TEMP
+  B-TREE FOR GROUP BY`, and the `DISTINCT` analogue) — the rowid is the table's own
+  clustered key, so there is no secondary-index *choice* and thus no cost-model
+  divergence; the seek returns rows in rowid order, never the group/distinct-key
+  order, so the b-tree is always needed. Gated in `eqp_select` on a
+  `SEARCH … INTEGER PRIMARY KEY (rowid>?/<?)` access line (a rowid *equality* seek is a
+  single row → excluded), reusing `group_distinct_btree`'s existing "a secondary index
+  leads the first key column → decline" guard. *Still open (folded into B9h):* the
+  same node under a **secondary-index** seek (`WHERE b=? GROUP BY c`), where SQLite may
+  pick a *different* composite index `(b,c)` whose walk serves the grouping — a
+  cost-model index-choice decision.
 - **B9e — `col = (scalar subquery)` seek. ✅ Done (SELECT).** `WHERE b = (SELECT …)`
   (and `>`/`<`/etc.) against a non-correlated scalar subquery now seeks — the executor
   folds the subquery to its value before the seek (`scan_source` single-table fast path),
@@ -1245,9 +1254,13 @@ tie/representative order), so they are perf/EQP-fidelity work, not correctness:
   longest-equality-prefix only. It also decides *whether* a no-WHERE query uses a
   covering scan at all (SQLite: narrow index beats a wide-row table scan, plain scan
   beats it on a 2-column table) — so the covering-scan row-order parity (formerly B9i)
-  rides here too. This changes the chosen access path, so it risks regressing the EQP
-  corpus and must be rolled out shape-by-shape with the full differential suite — the
-  single-table analogue of B1b.
+  rides here too, as does the **secondary-index** `SEARCH` + `GROUP BY`/`DISTINCT`
+  b-tree left open by B9d. This changes the chosen access path, so it risks regressing
+  the EQP corpus and must be rolled out shape-by-shape with the full differential suite
+  — the single-table analogue of B1b. **Confirmed deferred by design (2026-07-04):** the
+  pinned `sqlite3 3.50.4` oracle has no stat4, so its choices depend on row-width /
+  index-width / index-count heuristics graphite can't reproduce without diverging the
+  EQP corpus — same class as B1b/B4. Needs a stat4-enabled oracle to become tractable.
 - **B9i — covering-scan no-`ORDER BY` row order → subsumed by B9h (investigated
   2026-07-04, nothing to fix in isolation).** The original premise was wrong: graphite's
   covering read is *already* in index-walk order, and whenever graphite and SQLite pick
@@ -1261,12 +1274,22 @@ tie/representative order), so they are perf/EQP-fidelity work, not correctness:
   with two, so the plan **and** the emitted order differ. Reproducing it is pure cost
   modelling (row width, index width, number of indexes) — the same B9h/B4 problem, so
   the row-order parity rides on B9h, not a separate execution-order change.
-- **B9j — collation-aware index *selection* for a non-default-collation index.**
-  `collect_eq_constraints`/`collect_range_constraints` now compare an explicit
-  `COLLATE` to the *column's* collation (fixes the common bug); a `CREATE INDEX …
-  (b COLLATE NOCASE)` on a BINARY column plus a matching `COLLATE NOCASE` predicate
-  could seek that index, but graphite scans. Fully correct needs per-candidate-index
-  collation comparison threaded through every seek site.
+- **B9j — collation-aware index *selection* for a non-default-collation index.
+  Deferred (entangled, rows already correct).** `collect_eq_constraints` /
+  `collect_range_constraints` compare an explicit `COLLATE` to the *column's*
+  collation. When an index carries a *non-default* collation (`CREATE INDEX ib ON
+  t(b COLLATE NOCASE)` on a BINARY column), graphite is wrong in **both** directions vs
+  sqlite: `b='x' COLLATE NOCASE` should seek `ib` (graphite scans), and `b='x'` (BINARY
+  comparison) should *not* seek the NOCASE `ib` (graphite over-seeks it — rows still
+  correct via the WHERE re-apply, only EQP/perf). The correct model — an index serves a
+  comparison iff its per-column collation equals the comparison's *effective* collation
+  (explicit `COLLATE`, else the column's) — must be threaded into the index *selection*
+  at every one of the ~9 `collect_eq_constraints` call sites (the seek fast paths,
+  `eqp_access`, and `seek_order_prefix`'s ORDER-BY credit) in lockstep. The current
+  column-collation gate in the collector is itself an earlier ORDER-BY-ordering
+  correctness fix, so moving the check risks the extensive collation/seek/order suite
+  for a niche pattern with rows already correct. Deferred; a careful cross-cutting
+  refactor, not a quick slice.
 
 **Blocked / deferred by design:**
 - **B1b — cost-based join reordering.** graphite's per-cursor seek/bloom-filter

src/exec/mod.rs

@@ -14593,9 +14593,24 @@ impl Connection {
         // clean single-table bare-`SCAN` case, placed after the SCAN line and
         // before any ORDER BY node — matching sqlite's node order.
         let mut group_btree_suppresses_order = false;
+        // The GROUP BY / DISTINCT temp-b-tree also materializes over an *unambiguous*
+        // access path that doesn't already yield the grouping order: a bare `SCAN`, or
+        // a rowid RANGE seek (`SEARCH … INTEGER PRIMARY KEY (rowid>?…)`), which returns
+        // rows in rowid order — never the group/distinct-key order — and, being the
+        // table's own clustered key, involves no secondary-index *choice* (so no
+        // cost-model divergence, unlike a secondary-index seek — see roadmap B9h). A
+        // rowid *equality* seek is a single row (grouping is a no-op), so it is
+        // excluded. `group_distinct_btree`'s own "a secondary index leads the first key
+        // column" guard still declines the shapes where sqlite would walk an index.
+        let rowid_range_seek = single_scan_detail.as_deref().is_some_and(|d| {
+            d.starts_with(&alloc::format!(
+                "SEARCH {label} USING INTEGER PRIMARY KEY (rowid"
+            )) && (d.contains('>') || d.contains('<'))
+        });
         // A no-op `DISTINCT` (its projection pins the rowid/IPK, so it removes
         // nothing) is planned by sqlite as if absent — no `FOR DISTINCT` node.
-        if single_scan_detail.as_deref() == Some(alloc::format!("SCAN {label}").as_str())
+        if (single_scan_detail.as_deref() == Some(alloc::format!("SCAN {label}").as_str())
+            || rowid_range_seek)
             && !self.distinct_is_noop(sel, &meta, &label)
         {
             if let Some((kind, suppress)) =

tests/eqp_seek_group_btree.rs

@@ -0,0 +1,96 @@
+//! B9d (unambiguous subset) — the `USE TEMP B-TREE FOR GROUP BY` / `FOR DISTINCT`
+//! node materializes over a rowid *range* seek, not just a bare `SCAN`. A
+//! `WHERE a>? GROUP BY c` (a the INTEGER PRIMARY KEY, c not the seek key) seeks the
+//! rowid range — an unambiguous access path with no secondary-index *choice* — and
+//! returns rows in rowid order, which is never the grouping order, so SQLite (and now
+//! graphite) emit the grouping b-tree: `SEARCH t USING INTEGER PRIMARY KEY (rowid>?)#
+//! USE TEMP B-TREE FOR GROUP BY`. graphite previously omitted the node under any seek.
+//!
+//! A rowid *equality* seek (single row → grouping is a no-op), a GROUP BY on the rowid
+//! itself, and a secondary-index seek (where SQLite may pick a different composite
+//! index — cost-model, roadmap B9h) all stay as before. Verified vs sqlite3 3.50.4.
+
+#![cfg(feature = "std")]
+
+use std::process::Command;
+
+fn sqlite3_available() -> bool {
+    Command::new("sqlite3").arg("--version").output().is_ok()
+}
+
+fn plan(bin: &str, base: &str, sql: &str) -> String {
+    let full = format!("{base} EXPLAIN QUERY PLAN {sql}");
+    let out = Command::new(bin)
+        .arg(":memory:")
+        .arg(&full)
+        .output()
+        .unwrap();
+    String::from_utf8_lossy(&out.stdout)
+        .lines()
+        .filter(|l| !l.trim().is_empty() && !l.starts_with("QUERY PLAN"))
+        .map(|l| l.trim_start_matches(|c: char| " |`*+_-".contains(c)))
+        .collect::<Vec<_>>()
+        .join("#")
+}
+
+fn rows(bin: &str, base: &str, sql: &str) -> String {
+    let full = format!("{base} {sql}");
+    let out = Command::new(bin)
+        .arg(":memory:")
+        .arg(&full)
+        .output()
+        .unwrap();
+    String::from_utf8_lossy(&out.stdout).trim_end().to_string()
+}
+
+// A single secondary index (on b) so the rowid-seek cases are unambiguous; c is
+// deliberately un-indexed so no index serves the GROUP BY / DISTINCT.
+const SCHEMA: &str = "CREATE TABLE t(a INTEGER PRIMARY KEY, b, c); CREATE INDEX ib ON t(b);";
+
+#[test]
+fn rowid_range_seek_group_distinct_btree_matches_sqlite() {
+    if !sqlite3_available() {
+        eprintln!("sqlite3 CLI not found; skipping");
+        return;
+    }
+    let g = env!("CARGO_BIN_EXE_graphitesql");
+    for q in [
+        // Now emit the b-tree over the rowid range seek.
+        "SELECT c FROM t WHERE a>3 GROUP BY c",
+        "SELECT c FROM t WHERE a>3 AND a<9 GROUP BY c",
+        "SELECT DISTINCT c FROM t WHERE a>3",
+        "SELECT c, count(*) FROM t WHERE a>=2 GROUP BY c",
+        "SELECT c FROM t WHERE a>3 GROUP BY c ORDER BY c", // ORDER BY folded into the b-tree
+        // Unchanged: rowid equality (single row → no b-tree), GROUP BY the rowid,
+        // bare scan, and a secondary-index-served grouping.
+        "SELECT c FROM t WHERE a=3 GROUP BY c",
+        "SELECT c FROM t WHERE a>3 GROUP BY a",
+        "SELECT c FROM t GROUP BY c",
+        "SELECT DISTINCT c FROM t",
+    ] {
+        assert_eq!(
+            plan("sqlite3", SCHEMA, q),
+            plan(g, SCHEMA, q),
+            "plan for {q}"
+        );
+    }
+}
+
+#[test]
+fn rowid_range_seek_group_rows_match() {
+    if !sqlite3_available() {
+        eprintln!("sqlite3 CLI not found; skipping");
+        return;
+    }
+    let g = env!("CARGO_BIN_EXE_graphitesql");
+    let base = format!(
+        "{SCHEMA} INSERT INTO t VALUES(1,10,5),(2,20,5),(3,30,7),(4,40,5),(5,50,7),(6,60,9);"
+    );
+    for q in [
+        "SELECT c FROM t WHERE a>3 GROUP BY c ORDER BY c",
+        "SELECT DISTINCT c FROM t WHERE a>2 ORDER BY c",
+        "SELECT c, count(*) FROM t WHERE a>1 GROUP BY c ORDER BY c",
+    ] {
+        assert_eq!(rows("sqlite3", &base, q), rows(g, &base, q), "rows for {q}");
+    }
+}