ottyl/tickets/081-promql-dashboard-queries-rebuild-full-series-from-scratch-per-poll.md

081 — PromQL dashboard queries rebuild full label→points maps from scratch every poll

Summary

A dashboard panel backed by a PromQL-style query re-evaluates its entire series (all labels, all points) from scratch on every polling interval, with no reuse of the previous evaluation's work and no incremental narrowing by the time range the panel actually needs — same "narrow the range, don't rescan everything" principle as the other read-path tickets, applied to the dashboard/metrics query path this time.

Where

• evaluate_promql and its helpers (src/engine/snapshot/query.rs:412-548) build label→points maps for the query's underlying metric(s) fresh on every call — there is no reuse across repeated calls with the same query string and an overlapping time window, which is exactly the pattern dashboard polling produces (webapp/src/lib/polling.ts re-requests the same panel query on an interval).
• This sits on top of bucket_values (ticket 078), so once that's narrowed to a metric's own key range, evaluate_promql still recomputes the full aggregation/label-grouping logic over whatever bucket_values returns, every single call, even for the portion of the time range it already computed on the previous poll.

Scope

• Start by checking whether panels pass a time range/step down to evaluate_promql at all — if they do, apply the same key-range narrowing as ticket 077/078 first (bound the underlying bucket_values range by the panel's requested window) before considering caching, since that alone may remove most of the redundant work.
• If polling the same query with an advancing time window is common (sliding dashboard windows), investigate caching prior evaluation results keyed by (query string, label set) and only computing the delta for the newly-advanced portion of the window — this is more involved (needs a cache invalidation story tied to new bucket ingestion, similar to sort_helper_indexes' purge_stale_sort_helper_indexes, src/engine/snapshot/sort.rs) — do not build this speculatively without first confirming via profiling that repeated PromQL evaluation (not bucket_values scanning, addressed by ticket 078) is the actual bottleneck for dashboards with multiple panels.

Depends on

Should land after ticket 078 (metric bucket range narrowing), since that changes what evaluate_promql is scanning underneath and may reduce the size of this problem before any caching work is designed.