refactor: run query-side computation as Planner physical DAGs

[zzylol]

Stacked on #800.

Why

Planner's physical_planner::compile now covers the query-side computation the backend still lowered itself. The backend re-parsed PromQL text to recover operators, kept its own operator graph (QueryTimeOperator Binary/Aggregate/Sort/Limit/Temporal/Subquery and QueryPlanNode Scalar/Binary/ReduceSum), translated it to label-map operators, and evaluated subquery grids in the data plane. That is a second lowering of the same computation.

What

• The backend lowers only stored-state readouts (ReadMaterialization, ExactReadout, SummaryEstimate, SummaryMerge, current series). The query-time region above them is compiled once by physical_planner::compile, with the readouts as input contracts, into one PhysicalFragment.
• A root that Planner cannot compile over readouts keeps no state. The whole query goes to the exact engine (ExactFallback, forwarded unchanged). Queries that Planner keeps pre-ASAP are handled the same way.
• Deleted: query_time::Lower, compile_logical, the query_time_nodes/selected_* text witnesses, physical_values.rs, the DagCompiler Binary/Logical/Scalar/ReduceSum arms, the computation variants of QueryTimeOperator and QueryPlanNode, and the data-plane subquery grid and logical evaluation. Counter and range-maximum materializations are now identified from the selected node.
• Raw-series programs (Physical, from feat: bind query-time raw series inputs to the Prometheus endpoint #792) record whether PromQL drops __name__ from the result. The adapter removes it when decoding series identities. Planner keeps it.

Before / After

sum by (job) (rate(errors_total[5m])) / sum by (job) (rate(requests_total[5m]))

	Installed query nodes
Before	Frag[VectorBinary, Project×3, Aggregate×2] built by physical_values from re-parsed Logical Aggregate/Binary nodes over two ExactReadout
After	two ExactReadout → one Planner PhysicalFragment[Join, Project, SummaryBuild, Readout ×2]

topk(2, sum by (job) (rate(m[1h]))) with an unbindable child: before, Prometheus computed the child and the backend ran topk. After, Prometheus answers the whole query.

Startup on the warm test (collector_free_profile_serves_complete_matrix_and_falls_back_exactly, three runs each): 3.32/3.27/3.24 s before, 3.14/3.09/3.13 s after.

Behaviour differences

• Per-series arithmetic over stored readouts is forwarded whole. Planner's Binary does not yet match per-series rows (coverage Remaining 3). Affected queries were warm before and are now exact: avg_over_time(x[5m]) (sum/count), rate(a[5m]) / rate(b[5m]), rate(x[5m]) * 2, and sum_over_time(a[1m]) + sum_over_time(a{job="x"}[1m]). Grouped forms such as sum(...) / sum(...) and sum(...) * 2 stay warm. The issue 701/702 tests are updated to match.
• A computation over an exact PromQL subtree, such as topk over an unbindable child, is forwarded whole instead of being split between Prometheus and the backend.
• Some roots failed to compile before and are now forwarded: -sum(rate(x[5m])) now runs warm, and min by (job) (...) and mixed MetricsQL counter queries are now exact.
• An ephemeral state is chosen only when a raw-series program compiles. The per-leaf "externalizable" path is gone.
• A query that compiled state but cannot bind it now fails its candidate, where before it was mixed or errored. Its state is never maintained unread. A query with no compiled state is forwarded whole in every mode.
• An instant count, which has no local exact readout, is never an input to a Planner fragment.
• Raw-series results no longer carry __name__ where PromQL drops it.
• Persisted plans that contain the removed variants no longer deserialize.

Remaining backend computation

• SummaryEstimate / ExactReadout / SummaryMerge computation in post_asap_readout.rs (coverage row 16 is Partial; rows 15 and 17 need Planner-typed stored state bindings).
• Current-series Sum/Count/Average/Quantile/TopK readouts in storage_engines/sketch_db/current_series.rs are moved in the stacked refactor: compute current-series readouts as Planner physical programs #799.
• Uncovered shapes are forwarded: histogram_quantile, comparisons and set operators, group_left/right, per-series Binary over readouts, and implicit subquery resolution.
• The control plane no longer emits ExactSubquery/CandidateExactSubquery. Their data-plane runtime (exact_subqueries.rs, which re-parses PromQL to inject candidate matchers) is dead for new plans and can be removed in a follow-up.
• The metric-name rule cannot tell bool comparisons apart, because the IR does not record bool. Planner compiles no comparison yet.

Validation

• cargo fmt --all -- --check, cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo test --workspace --locked --lib, cargo test -p control_plane --locked --tests
• cargo test -p data_plane --locked --test asapquery_compatibility_process_e2e -- --test-threads=1 (26 passed)
• New tests: a grouped ratio and a topk execute as one Planner fragment over readouts. The o11y corpus uses only Planner fragments or whole forwarding. Per-series averages, topk over exact children and mixed MetricsQL counters forward whole. Raw-series results drop __name__. The retired operator variants are rejected.
• An independent review agent, which did not write the code, found five issues. Forwarding happened after placement and left state unread. Non-mixed deployments failed on unselected states. Pruned joins below the root were not guarded. Instant counts reached fragment inputs. The metric-name rule had gaps. All five are fixed with regression tests in the follow-up commits, and a re-review found no regressions.

🤖 Generated with Claude Code