Clarify CostModel mixed planner responsibilities

[milindsrivastava1997]

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.

[milindsrivastava1997]

More concretely, today search_workload does several things at once:

search_workload
  -> CSE
  -> discover every target subexpression
  -> construct context-dependent strategies
      - rollup
      - accuracy reconciliation
      - top-k reuse
  -> run strategies to a fixpoint
  -> generate candidates
      - post-ASAP SummaryNode candidates
      - pre-ASAP logical rewrite candidates
  -> use CostModel inside some strategies
  -> return PlanSpace

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:

whether a candidate is generated
what concrete parameters it has
whether a runtime supports it
whether it is selectable
how it ranks
how its lifetime is priced

[milindsrivastava1997]

Proposed flow

SQL / PromQL
  -> pre-ASAP workload
  -> validate and generate alternatives
  -> discard illegal alternatives
  -> discard runtime-unsupported alternatives
  -> rank remaining alternatives by cost
  -> select or materialize one post-ASAP plan

The stages answer different questions:

Strategy and legality model:
  This candidate correctly implements the requested query.

Runtime capability model:
  This deployment can execute this candidate.

Cost model:
  Among candidates that are correct and executable,
  this is the preferred one for this workload.

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.