Add a batched exact-window query API to the store #609
Description
Once #608 routes Sliding-window range queries through query_precomputed_output_exact (one call per output step instead of one wide scan), a range query over N output steps issues N sequential exact-window store calls where it previously issued one scan call. Even after #607 removes the write-lock cost, that's still N separate lock-acquire-and-lookup round trips instead of one.
Proposal
Add a batched variant, e.g. query_precomputed_output_exact_batch(metric, aggregation_id, windows: &[TimestampRange]) -> Result<Vec<TimestampedBucketsMap>, _> (exact shape TBD), that acquires the store shard lock once and resolves all requested exact windows against MutableEpoch/SealedEpoch in a single pass, instead of one lock cycle per window.
Scope
asap-query-engine/src/stores/traits.rs— new trait method.asap-query-engine/src/stores/simple_map_store/{per_key,global}.rs— implementation.asap-query-engine/src/engines/simple_engine/mod.rs— range pipeline's per-step Sliding fetch (from Range queries over Sliding-window aggregations use overlap-scan fetch, not exact-window fetch #608) becomes one batched call up front instead of a call inside the per-step loop.
Sequencing
Pure perf follow-up, no correctness bug riding on it — #608's fix is correct with sequential exact calls today. Land after #607 and #608, whenever convenient.
Activity
milindsrivastava1997 commentedon Aug 25, 2026
Confirming scope while planning #608: #608 will ship with N sequential exact calls in the per-step loop (no batching, no dedup across overlapping windows) — #609 will replace those N calls with one batched call later, as its own follow-up. #608 is not blocked on this landing first.
milindsrivastava1997 commentedon Aug 26, 2026
Scope suggestion: once this API exists, it should also become the implementation for
scan_windows_via_exact(asap-query-engine/src/engines/simple_engine/mod.rs, added in #616), not just the #608 Sliding per-step fetch.scan_windows_via_exactis the general non-exact-query fetch path (Tumbling range/instant queries, and non-DeltaSetAggregatorkeys queries) — it currently walks the aggregation's window grid and issues onequery_precomputed_output_exactcall per grid position in a loop, same shape as the N-sequential-calls problem this issue describes for #608's Sliding case, just triggered by a wide Tumbling range or a fine-grained keys query instead. A code review on #616 flagged this as a real perf concern (each grid position pays its own lock/lookup round trip) for e.g. a multi-day range query at 15s resolution.Once the batched API lands,
scan_windows_via_exactshould build its full list of grid positions up front and hand them to one batched call instead of looping — same fix, same API, just a second call site. Doesn't cover theDeltaSetAggregatorfallback case inscan_windows_via_exact(that one's[0, end_timestamp]range can be too wide to even enumerate, so it stays on the old scan regardless), but it should cover everything else that currently loops.Worth adding to Scope above alongside the #608 range-pipeline call site.
fix(query-engine): restore lock_profiling on batch exact-query, dedup…
feat(store): added store interface for batched exact-window queries (#…