Physical plans for simple repeated PromQL workloads: min_over_time fails to compile; windows ignore query cadence

[milindsrivastava1997]

Environment

• Tool: control_plane --example inspect_physical_dag (normal BackendLocalPlanningSnapshot::compile path)
• Snapshots: version 1, derived from docs/examples/asapquery-compatibility-demo-snapshot.json;
  source_sample_interval_ms = 1000, horizon_seconds = 3600, no window_candidates supplied.
  Quantile/topk queries use EpsilonDelta { epsilon: 0.01, delta: 0.01 }; sum/count/min/max use implicit_exact.

Workloads

Metric data, scraped every 1s.

id	queries	repeats every	range
w1	10 × quantile_over_time(φ, data[15m]), φ ∈ {0.5 … 0.999}	1m	15m
w2	1 × quantile_over_time(0.9, data[5m])	30s	5m
w3	5 × quantile by (job) (φ, data)	1s	instant (lookback 1s)
w4	5 × quantile_over_time(φ, data[5m]) + 5 × quantile by (job) (φ, data)	10s / 1s	5m / instant
w5	1 × quantile_over_time(0.9, data[5m]) / quantile_over_time(0.5, data[5m])	1m	5m
w6	sum_over_time, count_over_time, min_over_time, max_over_time of data[5m]; topk(5, sum_over_time(data[5m])), topk(5, count_over_time(data[5m]))	30s	5m

Installed materialized state

From install_request.precompute_plan.materializations:

id	sketch	grouping	window type	size	slide	layout
w1	DDSketch α=0.01	none (per entity)	tumbling	900s	900s	pane 900s
w2	DDSketch α=0.01	none (per entity)	tumbling	300s	300s	pane 300s
w3	DDSketch α=0.01	job	tumbling	1s	1s	pane 1s
w4	DDSketch α=0.01	job	tumbling	1s	1s	pane 1s
	DDSketch α=0.01	none (per entity)	tumbling	300s	300s	pane 300s
w5	— (no materialization; QueryPlan is a single exact_fallback)
w6*	Sum (serves sum_over_time and count_over_time)	none (per entity)	tumbling	300s	300s	pane 300s
	MinMax (serves max_over_time)	none (per entity)	tumbling	300s	300s	pane 300s
	CountSketchWithHeap d=5 w=512 heap=5 (topk of sum)	grouped	tumbling	300s	300s	pane 300s
	CountMinSketchWithHeap d=5 w=512 heap=5 (topk of count)	grouped	tumbling	300s	300s	pane 300s

* w6 with min_over_time removed; see below.

Multiple queries on one population share state as expected (w1: 10 queries → 1 materialization; w4: 10 → 2).

Bug 1: min_over_time does not compile

w6 fails, and min_over_time(data[5m]) fails on its own:

Error: QueryPlan(Invalid("materialized query has no compiled executable DAG"))

max_over_time(data[5m]) in the same snapshot compiles to a MinMax materialization. The other five
w6 queries compile together once min_over_time is removed.

Bug 2 (suspected): window slide ignores query evaluation interval

Every materialization is tumbling with slide = size = query range, even when the query repeats much
more often than its range:

• w1: 15m range evaluated every 1m → one 900s tumbling pane
• w2: 5m range every 30s, w4: 5m range every 10s → one 300s tumbling pane

A 900s tumbling pane covers (t-15m, t] only at 15-minute boundaries. Expected either a sliding
window whose pane width divides the 60s evaluation interval, or a compile-time rejection/exact routing.
Runtime behaviour at non-aligned evaluation times (stale answer vs. exact fallback) is not yet verified.

Observation: w5 routes the quantile ratio to exact execution

logical_selection shows Planner selected a DDSketch summary for each
quantile operand, but rejected the division root:

composed guarantee (AbsoluteValue, bound None, failure probability None) does not satisfy EpsilonDelta { epsilon: 0.01, delta: 0.01 }

Question: is exact routing the intended outcome for a ratio of two ε-approximate quantiles over the same
range, or should the operands be served from one shared DDSketch?

[milindsrivastava1997]

By default each query gets exactly one window option: a tumbling window equal to the query's range, stored as one pane. window_candidates lets the snapshot replace that option with its own list for a query. It only affects compile-time choices, and nothing in it (or anywhere in compile) looks at how often the query runs. The design doc says that's deliberate: the server checks pane alignment at query time and falls back to Prometheus.

The default window option

It's built in planning_request (control_plane/src/physical/compiler.rs:633-649). For a query whose PromQL text isn't a key in window_candidates:

WindowImplementationCandidate {
    implementation_id: implementation.window_implementation_id,   // "backend-tumbling-v1", copied from the snapshot
    framework:         Tumbling,
    window_secs:       lookback_ms / 1000,                         // the query range, e.g. 300 for [5m]
    slide_secs:        lookback_ms / 1000,                         // same as the window
    layout:            Pane { pane_secs: lookback_ms / 1000 },     // one pane covering the whole window
    cost:              implementation.implementation_cost,         // the snapshot's single cost number
                                                                   // (workload_fingerprint and horizon overwritten)
}

This single option comes only from the query's range. It never uses the query's repeat interval or source_sample_interval_ms.

[milindsrivastava1997]

None of the workloads in this issue set implementation.window_candidates, so every query in all of them gets the default window option described above.

• The field isn't in the snapshots. They were derived from docs/examples/asapquery-compatibility-demo-snapshot.json, which doesn't have it.
• The code still looks it up, and finds nothing. planning_request checks the (empty) keys at control_plane/src/physical/compiler.rs:560, and the per-query lookup at compiler.rs:633 falls back to the default every time.
• Debug prints confirm it. Temporary eprintln! calls after the planning queries are built show all 33 queries with no snapshot-supplied candidates and a single backend-tumbling-v1 option.

workload	window_candidates	queries on the default
w1	absent	10 / 10
w2	absent	1 / 1
w3	absent	5 / 5
w4	absent	10 / 10
w5	absent	1 / 1
w6	absent	6 / 6