You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(eqp): render LIST SUBQUERY + BLOOM FILTER for a non-correlated IN (SELECT) (B9a)
A single non-correlated `[NOT] IN (SELECT …)` in the WHERE now renders a
`LIST SUBQUERY 1` node (child: the body's plan, then a `CREATE BLOOM FILTER`
child) after the table access, matching SQLite — graphite previously rendered
just the bare access.
Gated to the provably byte-exact subset so nothing is emitted into a
non-matching plan: graphite's access is a bare `SCAN` (so there is no seek to
diverge from SQLite's cost-model outer choice — an `… AND c=?` that graphite
seeks makes the line a SEARCH and declines here, dodging the cases where SQLite
scans-plus-bloom where graphite would seek), and either the form is `NOT IN`
(never seeks the IN column) or the IN column is not seekable (so SQLite also
scans). This covers the common `NOT IN (SELECT …)`. A positive `IN` on an
indexed / rowid column (SQLite serves a per-candidate SEARCH), and a correlated /
compound / cross-position subquery, keep graphite's prior bare SCAN — the
executor per-value seek is a documented follow-up (B9a-seek).
New free fns collect_in_selects / single_where_in_select. Removed the now-handled
`b IN (SELECT)` case from the scalar-subquery decline test.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
0 commit comments