feat(planner): export a planned workload as one physical ASAP DAG

[zzylol]

Why

With the planner on the unified IR (#542), a planned workload can be handed to the deployment runtime (Stage 4) as one physical DAG, and the summary coverage that #646 derives from the node can be checked end to end from real queries.

What

• One physical DAG per planned workload. PlanOutput::execution_timed_dag() times every query root, and every operator sub-DAG a standalone scalar query reads (refactor(planner): plan the workload on the unified operator IR #542), with one shared TimingMemo, and exports a single PhysicalASAPDAG: one root per operator query, one scalar_roots entry per scalar query, shared sub-DAGs and states once. Scalar roots are keyed by position in the batch, which equals the entry index because check_contract requires dense entry indices. An empty workload returns PhysicalASAPDAGValidationError::NoRoots; a workload of only literal scalars yields a DAG with no nodes, just its scalar_roots.
  • Execution timing in this PR still follows the summary maintenance lifecycle selected for each deployment, including the plans of scalar-read sub-DAGs; refactor(planner): replace the summary lifecycle with #509 materialization options #667 removes the lifecycle and times the export from the docs: propose workload-wide planning, summary sharing, and materialization #509 materialization options instead.
  • The helper behind it (execution_timed_workload_dag) is crate-private; only PlanOutput::execution_timed_dag is public, and the per-plan SummaryMaintenanceLifecyclePlan::execution_timed_dag is the batch of one.
• Coverage from queries (docs: ASAP primitive schema and summary coverage (definition + selection) #573). crates/integration-tests/tests/summary_coverage_e2e.rs (new) lowers the docs: ASAP primitive schema and summary coverage (definition + selection) #573 §4.2.2 example queries through the SQL and PromQL frontends, runs candidate search, and checks both parts of coverage() on the KLL SummaryAgg: the definition (what the summary is built over) and the selection (what it covers). Each test takes the one KLL SummaryAgg among the search space's candidates, so the tests do not depend on which candidate DefaultCostModel selects.

How

execution_timed_dag reuses #541's compile_physical_asap_workload_with_node_ids over the planned roots. The coverage tests read OperatorNode::coverage() on the KLL summary candidate; coverage is derived from the node, nothing is declared by the planner.

Before this PR

Each planned query could be exported only on its own, and coverage was checked only on hand-built nodes (#646).

After this PR

A planned batch exports as one PhysicalASAPDAG, and the coverage derivation is tested on SQL and PromQL queries through the frontends and Pass 1 candidate generation. New public API: PlanOutput::execution_timed_dag.

Evidence

From summary_coverage_e2e.rs: SQL region = 'us' → region ∈ {us}; latency < 100 → latency ∈ (−∞, 100); a renamed column (region AS r) → r ∈ {us}, with latency * 2 > 10 kept in the definition's scan; PromQL quantile_over_time(0.99, m[1m] offset 2m) → relative time (−3m, −2m]; quantile(0.99, rate(m{job="api"}[5m])) → unrestricted selection, with the matcher kept in the definition (it is below rate); quantile(0.99, rate(m[5m]) > 0) → value ∈ (0, ∞). From operator_design_examples.rs: a two-query batch exports with two roots and one shared SummaryAgg.

Verification

• Coverage tests in summary_coverage_e2e.rs: sql_where_value_set_moves_to_selection, sql_where_range_moves_to_selection (exactly one box; the scan predicate is removed from the definition), sql_renamed_column_moves_and_expression_stays, promql_offset_window_is_relative_time, promql_matcher_below_rate_stays_in_definition, promql_comparison_above_rate_moves_to_selection, promql_vector_comparison_stays_in_definition (rate(a[5m]) > rate(b[5m]) is a BinaryOp, nothing selected) and promql_bool_comparison_stays_in_definition (> bool 0 is a Project, kept in the definition). The SQL tests also assert that the definition's SummaryAgg has no filter.
• Workload export: batch_planning_replaces_and_shares_summary_operators (one physical DAG, two roots, shared state once); scalar_queries_read_planned_summaries exports scalar roots keyed by entry that reference the shared summary.
• Other checks on the PR head: cargo fmt --check; workspace all-target Clippy with -D warnings; cargo test --workspace (1,734 passed, 0 failed, 2 ignored); dag-viewer test_render (31 passed); tools/verify_metricsql_external_consumer.sh OK.

Architectural decisions

Not applicable: both changes use existing interfaces.

Limitations and follow-up

• refactor(planner): replace the summary lifecycle with #509 materialization options #667 replaces the lifecycle-based timing of the export with the docs: propose workload-wide planning, summary sharing, and materialization #509 materialization options.
• The filtered worked example follows in Pass 1: single-measure filtered aggregates #608, where Pass 1 builds filtered states.

Stack: tracker #528 · main → #542 → #665 → #666 → #543 → #667 → #561.

Human review — do not complete with an agent

• The MVP boundary is correct.
• New conceptual layers or public interfaces are necessary.
• The before/after description matches the intended product behavior.
• Human reviewer:
• Decision and rationale:

🤖 Generated with Claude Code

https://claude.ai/code/session_01W7qG9aFyPij5uWsyAJCxDW