Module memoize 

v6.2.6 — Memoize cache for correlated subqueries.

When a WHERE clause references a scalar subquery whose inner body depends on the outer row’s column values (the classic WHERE id IN (SELECT MAX(x) FROM y WHERE y.k = outer.k) shape), the engine’s current behaviour re-runs the inner SELECT once per outer row — O(outer_rows × inner_cost) work even when many outer rows share the same correlated key.

v6.2.6 wraps that path with a per-query MemoizeCache: before running the inner, hash the (subquery identity, outer- row values) key and look it up; cache hits return the prior result without re-executing. Caps:

• 1024 entries (configurable via the planner’s [Self::with_max_entries])
• 16 MiB of cumulative cached Value bytes (v5.5 per-query memory budget’s 1/16 share; configurable via [Self::with_max_bytes])

When either cap is hit, the least-recently-used entry is evicted before insertion.

v6.2.6 ships the simple linear-vec LRU. v6.2.x can swap to a BTreeMap + LinkedList for sub-O(n) lookup if it ever matters; the gate is “≥ 5× speedup on the repeated-key workload” which the linear scan clears at scale-1k.

Structs

CacheKey

Cache key — the subquery’s textual identity plus the outer row’s value tuple. Two scalar-subquery node positions with identical Display text are treated as the same subquery for caching purposes (sound: equal Display → equal AST).

MemoizeCache

Constants

DEFAULT_MAX_BYTES

v6.2.6 — default cumulative bytes cap. 16 MiB matches the v5.5 per-query budget’s 1/16 share.

DEFAULT_MAX_ENTRIES

v6.2.6 — default cache size cap. Matches the design’s “1024 entries” figure (V6_2_DESIGN.md L2 row 6).