Repository navigation
Clarify CostModel mixed planner responsibilities #436
Description
Context
The planner intended flow is:
SQL / PromQL -> pre-ASAP IR -> replacement strategies propose candidates -> cost-based ranking and selection
CostModel is currently the primary deployment-facing extension point in that flow. The relevant interface is crates/asap-aware-mapping/src/cost_model.rs.
Current responsibilities
| Concern currently in CostModel | What it answers | Main consumer |
|---|---|---|
| Candidate ranking | Which supported sketch implementation is preferred? | SketchAlgorithmStrategy |
| Sketch sizing | What parameters meet the requested accuracy? | SketchAlgorithmStrategy |
| Grouping economics | Per-group summaries or a shared Hydra structure? | HydraGroupingStrategy |
| Extension realization | How does a deployment-specific aggregate become a summary and readout? | Replacement construction |
| CSE economics | Recompute each occurrence or share one maintained subtree? | SharedSubtreeStrategy |
| Recurrence economics | How do update rate, read rate, horizon, and build cost affect sharing? | Recurrence selection |
| Candidate pricing | What is the cost and availability of a replacement? | PlanSpace ranking and selection |
| Runtime capability | Can a value operation run at read time or maintenance time? | ExactCompositionStrategy |
| Lifecycle planning | Can a summary be created, updated, merged, or deleted, and at what cost? | Lifecycle planner |
| Complete physical-plan pricing | What is the end-to-end cost of a lowered physical DAG? | PhysicalPlanCostModel |
Problem 1: Scope creep in one trait
CostModel has accumulated responsibilities across candidate generation, implementation sizing, CSE, recurrence, runtime capability, lifecycle planning, and physical-plan evaluation. A consumer interested only in basic candidate ranking inherits defaults and contracts for unrelated areas.
This makes the interface difficult to understand and implement. It also makes changes in one planning area more likely to affect or constrain consumers that only need another area. The trait name no longer communicates the breadth of behavior it carries.
Problem 2: Mixing distinct decision concerns
The trait combines three different kinds of planner knowledge:
- Legality and semantic realization: for example, how an extension intent is realized and read out.
- Runtime executability: for example, whether the deployment supports an operation at read time or maintenance time.
- Economics: ranking candidates and estimating the cost of candidates, CSE choices, physical plans, and lifecycle alternatives.
These questions have different meanings and failure modes. A candidate can be semantically valid but unsupported by a particular runtime; an executable candidate can be more expensive than another executable candidate. Coupling the decisions makes it difficult to tell whether a strategy outcome reflects correctness, runtime support, unavailable evidence, or an economic preference.
Some defaults intentionally represent missing information rather than usable economic estimates, which further obscures which responsibility a deployment model is expected to provide. This makes the core frontend -> IR -> candidate generation -> ranking model harder to understand and evolve.
Activity
milindsrivastava1997 commentedon Sep 17, 2026
More concretely, today search_workload does several things at once:
For example, SketchAlgorithmStrategy asks CostModel to order sketch algorithms and size their parameters while it is generating candidates. ExactCompositionStrategy asks the same trait whether the runtime supports an operation. Later, PlanSpace::cost_sorted asks it to price and rank candidates. Lifecycle planning asks it for yet more runtime and economic information.
So today CostModel can affect:
milindsrivastava1997 commentedon Sep 17, 2026
Proposed flow
The stages answer different questions:
This does not preclude deployment information during candidate generation. For example, sketch sizing can require a deployment-supported parameter catalog. The distinction is that implementation availability and configuration are explicit inputs, rather than responsibilities of a trait named CostModel.