Repository navigation
Open
Labels
irPre-ASAP or post-ASAP intermediate representationPre-ASAP or post-ASAP intermediate representationoptimizerWorkload optimization and plan selectionWorkload optimization and plan selectionquestionFurther information is requestedFurther information is requestedwindowWindow functions, frames, panes, or temporal semanticsWindow functions, frames, panes, or temporal semantics
Description
Workload
Three repeating PromQL queries on ae7ae6c2, all every 10 s:
- Q1
rate(data[5m]) - Q2
rate(data[1m]) - Q3
increase(data[10m])
data is a counter with 10,000 series, one sample every 15 s per series (≈667 samples/s ingesting).
Save as wl.json:
{"query_workload": {"language": "promql", "query_batch": null, "repeating_queries": [
{"query": "rate(data[5m])", "demand": {"fixed_interval": 10000},
"requirements": {"accuracy": {"max_error": 0.01, "failure_probability": 0.001}},
"predictability": {"predictable": {"known_at": null}}},
{"query": "rate(data[1m])", "demand": {"fixed_interval": 10000},
"requirements": {"accuracy": {"max_error": 0.01, "failure_probability": 0.001}},
"predictability": {"predictable": {"known_at": null}}},
{"query": "increase(data[10m])", "demand": {"fixed_interval": 10000},
"requirements": {"accuracy": {"max_error": 0.01, "failure_probability": 0.001}},
"predictability": {"predictable": {"known_at": null}}}]},
"data_workload": {"arrival": {"ingesting": {"rows_per_second": 666.67}},
"sources": {"data": {"series_count": 10000, "metric_type": "counter", "sample_interval": 15000}}}}cargo run -p asap-devtools --bin stage_pipeline -- --workload wl.json --exhaustive --out out.jsonThis gives 16 logical plans, all exact: each query either does or doesn't build its window from 10 s panes (30, 6 and 60 panes), and the scan either is or isn't shared. A query in panes runs Scan → PaneChain → SummaryMerge → FinalizeExactAccumulator.
Questions
- Rate and Increase accumulators should be the same. The rate queries build
ExactAggregate [Rate, Rate]and the increase queryExactAggregate [Increase, Increase].rateisincreasedivided by the window, so the state per series should be the same, with only the final step differing. - There should be sharing across PaneChains. The windows are nested (1m ⊂ 5m ⊂ 10m) and all use 10 s panes, so Q2's 6 panes are the newest 6 of Q1's 30, which are the newest 30 of Q3's 60. However, only the scan is shared, not the PaneChains.
- Should
PaneChaincontain an explicitSummaryAgg? TodayPaneChaincarries the build's own fields (family,input,grouping,filter,reduction) pluspane_countandpane_width_ms, and there is noSummaryAggnode beneath it. Would it be clearer to model it as aSummaryAggper pane, withPaneChainonly describing the windowing?
Metadata
Metadata
Assignees
Labels
irPre-ASAP or post-ASAP intermediate representationPre-ASAP or post-ASAP intermediate representationoptimizerWorkload optimization and plan selectionWorkload optimization and plan selectionquestionFurther information is requestedFurther information is requestedwindowWindow functions, frames, panes, or temporal semanticsWindow functions, frames, panes, or temporal semantics
Activity
zzylol commentedon Oct 22, 2026
Additional matched-input control from the observability probe on
c3be284c97c1f7ecdc490d78ddecf3e5f78c2007(2026-10-22):Both queries have identical filters and grouping, repeat every 30 seconds, and require exact accuracy (
max_error: 0,failure_probability: 0). The counter has 1,000 series sampled every 15 seconds with ongoing ingestion.Exhaustive enumeration gives 8 logical candidates, and selects
P2-m1: a shared scan at query time. None of the logical candidates shares rate/increase summary state or a common pane chain. Pane variants keep separateRateandIncreasefamilies (10 and 120 panes of 30 seconds).This supports the readout/state-sharing concern in this issue independently of differing filters: the original API-server production rules also differ in filters and grouping, but this control removes those differences.
Self-contained workload (save as
matched.json, then runstage_pipeline --workload matched.json --enforce-accuracy-guarantees --exhaustive --max-combinations 10000 --max-displayed 100 --out matched.out.json):{ "query_workload": { "language": "promql", "repeating_queries": [ { "query": "sum by (cluster, code, verb) (rate(apiserver_request_total{job=\"apiserver\",verb=~\"LIST|GET\"}[5m]))", "demand": { "fixed_interval": 30000 }, "requirements": { "accuracy": { "max_error": 0.0, "failure_probability": 0.0 } }, "predictability": { "predictable": { "known_at": null } } }, { "query": "sum by (cluster, code, verb) (increase(apiserver_request_total{job=\"apiserver\",verb=~\"LIST|GET\"}[1h]))", "demand": { "fixed_interval": 30000 }, "requirements": { "accuracy": { "max_error": 0.0, "failure_probability": 0.0 } }, "predictability": { "predictable": { "known_at": null } } } ] }, "data_workload": { "arrival": { "ingesting": { "rows_per_second": 66.66666666666667 } }, "sources": { "apiserver_request_total": { "sample_interval": 15000, "series_count": 1000, "metric_type": "counter" } } } }This evidence covers planning and executor compilation, not execution equality of a proposed shared state.