Repository navigation
MajorPass: pass the planning AccuracyModel to Pass 1 strategies — after #511 #523
Description
Problem
MajorPass builds Pass 1 candidates with the built-in accuracy model. PlanningModels::with_accuracy only affects the final root check. So a deployment-supplied empirical accuracy model, which #509 says is the deployment's input, cannot certify readouts during candidate generation. For example, UnivMon distinct, entropy and L2 have no calibrated built-in bound and can never be selected. Found while writing #519. Its certified_frequency_readouts_share_one_univmon_state test has to repeat MajorPass's steps by hand instead of going through e2e_plan.
Blocked on
Implementation of #511 (unified operator graph: OperatorNode with common metadata, no KeepPreAsap wrappers). Do not start before #511 is implemented.
Proposed
Thread PlanningModels.accuracy into the strategies MajorPass builds (SketchAlgorithmStrategy and the others), with no new types. Then port the UnivMon test from #519 to e2e_plan with a test accuracy model.
Activity
zzylol commentedon Oct 2, 2026
Please rename MajorPass as other explicit names.
zzylol commentedon Oct 15, 2026
Closing as obsolete:
MajorPassis gone, and the accuracy model no longer belongs in Pass 1.MajorPass. The planner pipeline is nowStage1ToStage3Pass(crates/asap-aware-mapping/src/pass/stage1_to_stage3.rs:run_stage1_to_stage3). refactor(planner): name the planner pipeline Stage 1 to Stage 3 and its fields by stage #675 named its fields by stage.crates/asap-aware-mapping/src/per_computation_candidates.rs:generate_per_computation_candidates, feat(planner): Stage 1 Pass 1 per-computation candidate generation #561) uses no cost or accuracy model. It prunes a candidate only when the candidate provably cannot meet its target. Ranking and discarding valid candidates belong to Stage 3.crates/asap-aware-mapping/src/stage3_plan_selection.rs:select_plan→accuracy_violation, feat(planner): physical ASAP-aware optimization and plan selection for candidate logical ASAP DAGs #576). A query's output meets its target whenmodels.accuracy.satisfies(...)accepts its root guarantee, or whenmodels.evidence.output_guarantee(root)does. SoPlanningModels::with_accuracy/with_evidencenow decide which candidates are selectable, not just a final root check.crates/integration-tests/tests/planner_layering_example2.rs,crates/devtools/tests/stage_pipeline.rs:example2_plans_the_sql_workload_with_one_univmon_for_all_three), so the hand-repeated test this issue mentions is no longer needed.