Recurrence-aware optimization: cost shared maintenance by query repetition

[zzylol]

Context

ASAPPlanner already models recurring workload metadata through RepeatingEntry and workload statistics through DataCharacteristics, but this metadata does not currently reach ASAP-aware search or CostModel. The current CSE share-vs-recompute decision considers the current structural consumers, not how frequently those consumers execute.

This issue adds a generic recurrence-aware cost context to ASAPPlanner. It does not add scheduling, Prometheus rule-group semantics, or a runtime execution loop.

Related: #194.

Cost semantics

All alternatives must be compared in the same time-normalized unit, initially cost units per second.

For a maintained summary:

maintained_cost_rate =
    update_rate * maintenance_cost_per_update
  + evaluation_rate * summary_read_cost

For recomputation from the pre-ASAP/raw path:

recompute_cost_rate =
    evaluation_rate * raw_recompute_cost

For a summary shared by multiple repeating consumers:

evaluation_rate = sum(1 / query_interval_i)

One-shot consumers must be represented separately from a steady-state rate. If a comparison includes both one-shot and repeating work, the caller/cost context must supply an explicit evaluation horizon H:

total_cost(H) = recurring_cost_rate * H + one_shot_cost

The cost model must not silently combine rate-valued and one-shot costs.

Repetition amortizes a maintained summary across more reads; it does not reduce the physical maintenance work caused by ingest updates.

Scope

• Carry RepeatingEntry.interval and relevant DataCharacteristics into ASAP-aware search/cost context.
• Extend CSE share-vs-recompute costing to use update rate and the aggregate evaluation rate of all effective consumers.
• Support a shared sub-DAG consumed by queries with different intervals.
• Keep caller/query identifiers opaque; ASAPPlanner needs only ownership needed to associate recurrence metadata with roots and consumers.
• Preserve existing behavior when recurrence or data-rate metadata is unavailable.
• Document units and provenance for every new cost input.

Out of scope

• Prometheus rule groups, phase, offset, for, keep_firing_for, missed iterations, Alertmanager, or scheduling.
• Executing queries repeatedly inside ASAPPlanner.
• Temporal-pane boundary selection, retention/lookback compatibility, window alignment, watermarks, and lateness. These require a separate window/retention reuse issue.

Acceptance criteria

• With a deterministic test cost model, identical IR at high evaluation frequency selects maintained/shared state while a sufficiently infrequent workload selects recomputation.
• Consumers with intervals t1..tn contribute sum(1/ti) to a shared summary's evaluation rate.
• Update rate affects maintained-summary cost but not read frequency; evaluation rate affects summary-read and recomputation cost.
• One-shot and repeating costs cannot be combined without an explicit horizon.
• Missing recurrence metadata preserves the current selection behavior.
• Tests cover mixed intervals, a one-shot consumer, multiple roots sharing a sub-DAG, invalid/zero intervals, and unit consistency.
• Cost/explanation output reports the selected alternative, both compared cost rates, their inputs, units, and model provenance.

Follow-up

Create a separate issue for temporal-pane reuse and retention/lookback legality across recurring queries.

[zzylol]

@milindsrivastava1997

[milindsrivastava1997]

Thanks. Need to wire in #194

[zzylol]

Related open work

• Activates the currently unused workload metadata described by QueryWorkload streaming fields (RepeatingEntry, DataCharacteristics) are unused — should be wired in #194; merely lowering RepeatingEntry is not sufficient unless recurrence reaches search/costing.
• Supplies an orthogonal cost input to Evaluate AHA-style sparse-subpopulation strategy vs. maintaining full hierarchical sub-population summaries #288.
• Its modeled decisions and inputs should be exported and visualized through (dev-tools) Export and visualize planner cost/benefit annotations #286.
• Candidate-plan search architecture is tracked by asap-aware-mapping: Cascades/Volcano-style candidate-plan search engine over ReplacementStrategy #252.