Module plan_cache 

Plan cache — Mission D9.

Two queries that differ only in literal values share the same parsed + planned tree. Re-running the lexer + parser + planner on every call is pure overhead — easily 1-3μs per query, which is the entire budget on sub-microsecond workloads like update_by_pk. SQLite gets around this with prepare_cached; we get around it with this cache.

How it works

1. crate::canonicalize::canonicalize lexes the input and produces (canonical_hash, literals). The hash collapses literal values into placeholders, so User filter .id = 1 and User filter .id = 2 have the same hash.
2. On the first call, PlanCache::insert stores the planned tree keyed by the canonical hash. The plan still has the first call’s literal values baked into its Expr::Literal nodes — that’s fine, we’ll overwrite them on subsequent hits.
3. On a subsequent call, PlanCache::get_with_substitution clones the cached plan and walks it depth-first, replacing each Expr::Literal it finds (in source order) with the corresponding literal from the new query.

The walk order is deterministic and matches the source order of the literal list collected by canonicalize — see the per-PlanNode comments below for the exact traversal contract.

Structs

PlanCache

LRU-ish plan cache keyed by canonical query hash.