Module exec 

Query execution. Each AND group is driven by a single SIMD sweep over the contiguous name pool (pool-scan / prefix / suffix drivers) that yields a sparse candidate list; residual matchers then verify only those candidates. Groups without a usable literal fall back to a chunked full scan, and the empty query walks the permutation directly. Results materialize as O(1)-pageable, sort-ordered id arrays (docs/ARCHITECTURE.md “query-time materialization”).

Structs

SearchMetrics

Per-volume stage timings for crate::metrics::QueryTrace.

SearchResult

One volume’s query result: the matching ids plus the index generations they were computed against (for staleness checks and incremental refine).

Constants

CHUNK 🔒

65536 entries per parallel task for full scans.

Functions

full_scan_group 🔒

materialize_filtered 🔒

Walk the pre-sorted permutation keeping entries that pass keep — parallel chunks, order preserved by concatenation. Name order is the always-maintained index column; size/mtime orders are lazily derived caches that build on the first query sorting by them (one parallel sort) and extend per generation after that.

path_memos 🔒

Build (or incrementally extend) exactly the dir-path memos this query reads — None pools cost nothing, which is the whole point of keeping folded and original-case memos in separate cache slots.

refine

Incremental refinement: when the previous query’s result provably contains the next one’s (subsume.rs) and the index generation is unchanged, filter the cached ids with a complete per-entry evaluation instead of sweeping pools and walking the whole permutation. prev_ids are already in the requested order, so the filtered subsequence is the answer — O(previous hits) instead of O(index).

search

Execute a compiled query against one volume index.