Latest Results
Reuse catalog indexes under stale rows and slow constraints
The packed-trie executor rejected the persistent catalog index whenever
the table had stale rows or the scan carried slow constraints, because a
cached probe borrowed its row group without filtering. The old executor
allowed both and filtered each match instead.
Restore the old eligibility rule (a large dense root with cacheable
columns) and attach a `CatalogFilter` to the cached probers: an
existence-only match must find a live row that passes the constraints
(new short-circuiting `Table::contains_match`), a constrained match with
retained rows materializes the survivors (inline when small, otherwise
a frame-local residual `TrieRoot` that never touches the plan-level
packed root slot), and an unconstrained match on a stale table is
borrowed as before, since every consumer of retained rows already skips
stale rows while scanning.
One case keeps the shared root projection: a constrained scan below a
root shared across plans. The catalog's shared continuation grid is
keyed by columns only, so a materialized constrained match could not
publish packed nodes into it, whereas the projection's grid is keyed by
those constraints and shares everything below it.
Eager stale-row filtering was measured as an alternative, per match and
once per key into the query arena with trusted-live downstream scans,
and was no faster on any benchmark (1-3% slower where the path is hot):
the in-scan stale check costs about a nanosecond per row, while any
per-key filter costs tens of nanoseconds per key.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Latest Branches
+8%
codex/recover-packed-backend-performance 0%
-5%
© 2026 CodSpeed Technology