feat(plan): add a CostModel interface for deployment-specific sketch ranking - #138
Merged
Merged
Conversation
…ranking asap-plan intentionally has no cost model implementation of its own -- ranking candidate sketches by real cost (bandwidth budget, memory footprint, site count, observed drift, ...) needs deployment knowledge this crate deliberately doesn't have (it depends only on asap-ir, never on a runtime or deployment model). Until now that meant no extension point at all: boundary::bind_sketch took sketch_candidates(intent) unconditionally by static-list order (.first()), and cost_model.rs was a 7-line stub with no callers. Add the CostModel trait (rank_candidates) plus DefaultCostModel, which preserves the existing static order exactly. boundary::realize_with and bind::bind_with/bind_in_with thread a &dyn CostModel through to bind_sketch's candidate selection; the existing realize/bind/bind_in entry points are unchanged (thin wrappers over the _with variants using DefaultCostModel), so this is purely additive -- no behavioral change for any existing caller. This gives each downstream deployment (ASAPCollector + ASAPQuery-backend, ASAPFusion, ...) one place to plug in its own cost-based sketch selection instead of forking bind_sketch. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
… naming sketch_candidates/bind_sketch_with predate this PR's CostModel interface, but the "sketch" in their names is narrower than what CostModel:: rank_candidates is meant to cover: SummaryKind already spans exact accumulators alongside approximate sketches, and non-sketch summary realizations (sampling-based, wavelet-transform, OMP/compressive-sensing) are expected to land as SummaryKind variants over time. Renaming to summary_candidates/bind_summary_with matches the established SummaryKind/ SummaryParams/SummaryExpr convention instead of introducing a competing "sketch" vocabulary for the same concept. Doc comments and one test name updated to match; no behavioral change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zzylol
added a commit
to ProjectASAP/ASAPQuery-backend
that referenced
this pull request
Jul 20, 2026
…nterface) Picks up ProjectASAP/ASAPPlanner#138: asap-plan's new CostModel trait (deployment-pluggable summary ranking) plus the sketch_candidates/ bind_sketch_with -> summary_candidates/bind_summary_with rename. No source changes needed here -- asap-ir/asap-l2 (what control_plane actually depends on) are unaffected by that PR; control_plane doesn't depend on asap-plan. cargo build/test -p control_plane clean (768 passed, 1 known pre-existing unrelated failure). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zzylol
added a commit
to ProjectASAP/ASAPQuery-backend
that referenced
this pull request
Jul 20, 2026
…ary::implementation_for Bumps the ASAPController pin to 12b3054 (ProjectASAP/ASAPPlanner#138-140: CostModel interface, realize/Realization -> implementation_for/Implementation Cascades-terminology rename, CountSketch/CountSketchWithHeap SummaryKind variants, Implementation::is_satisfied_by) and adds asap-plan/asap-sketch as new git dependencies (same repo/rev as asap-ir/asap-l2; asap-plan depends only on asap-ir, so this pulls in no datafusion/front-end weight). capability_for no longer maintains its own hand-written AggIntent -> ASAP-tier capability match -- that was a second, parallel judgment kept in sync with asap-plan's own implementation_for by hand (and had already drifted twice: the Count/Min-Max divergences fixed in a prior commit). It now keeps only the Extension/Frequency special case (deployment-specific -- asap-plan has no opinion on an intent shape it can't see into, by design) and delegates everything else to asap_plan::boundary::implementation_for, translating the returned Implementation into this repo's coarser Capability vocabulary via the new implementation_to_capability helper. One deliberate override survives the delegation: Count{Exact} is forced to None (archive) rather than trusting implementation_for's ExactAccumulator claim, because the data plane has no working count accumulator (SumAccumulator conflates Sum and Count). All 772 existing tests pass unchanged -- confirms the delegation is behaviorally identical to the hand-written match it replaces, including the Min/Max and Count fixes from the prior commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
zzylol
added a commit
to ProjectASAP/ASAPQuery-backend
that referenced
this pull request
Jul 21, 2026
…ary::implementation_for Bumps the ASAPController pin to 12b3054 (ProjectASAP/ASAPPlanner#138-140: CostModel interface, realize/Realization -> implementation_for/Implementation Cascades-terminology rename, CountSketch/CountSketchWithHeap SummaryKind variants, Implementation::is_satisfied_by) and adds asap-plan/asap-sketch as new git dependencies (same repo/rev as asap-ir/asap-l2; asap-plan depends only on asap-ir, so this pulls in no datafusion/front-end weight). capability_for no longer maintains its own hand-written AggIntent -> ASAP-tier capability match -- that was a second, parallel judgment kept in sync with asap-plan's own implementation_for by hand (and had already drifted twice: the Count/Min-Max divergences fixed in a prior commit). It now keeps only the Extension/Frequency special case (deployment-specific -- asap-plan has no opinion on an intent shape it can't see into, by design) and delegates everything else to asap_plan::boundary::implementation_for, translating the returned Implementation into this repo's coarser Capability vocabulary via the new implementation_to_capability helper. One deliberate override survives the delegation: Count{Exact} is forced to None (archive) rather than trusting implementation_for's ExactAccumulator claim, because the data plane has no working count accumulator (SumAccumulator conflates Sum and Count). All 772 existing tests pass unchanged -- confirms the delegation is behaviorally identical to the hand-written match it replaces, including the Min/Max and Count fixes from the prior commit. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
asap-plandeliberately has no cost model implementation of its own (it depends only onasap-ir, never on a runtime or deployment model) -- but until now it also had no interface for one:boundary::bind_summary_with(formerlybind_sketch) picked the static-order head unconditionally, andcost_model.rswas a 7-line stub with no callers (TODO(#6)/TODO(#33)).CostModeltrait (rank_candidates(intent, candidates) -> Vec<SummaryKind>, best first) plusDefaultCostModel, which preserves the existing static candidate order exactly.boundary::realize_withandbind::bind_with/bind_in_withthread a&dyn CostModelthrough to summary selection. The existingrealize/bind/bind_inentry points are unchanged -- thin wrappers over the_withvariants usingDefaultCostModel-- so this is purely additive, no behavioral change for any existing caller.bind_summary_with.sketch_candidates/bind_sketch_withtosummary_candidates/bind_summary_with(second commit):SummaryKindalready spans exact accumulators alongside approximate sketches, and non-sketch summary realizations (sampling-based, wavelet-transform, OMP/compressive-sensing) are expected to land asSummaryKindvariants over time -- naming the new interface around "sketch" would've introduced a second, narrower vocabulary for the same conceptSummaryKind/SummaryParams/SummaryExpralready name "summary".Test plan
cargo build --workspace-- cleancargo test --workspace-- all green, no regressionscargo clippy -p asap-plan --all-targets-- cleancargo fmt -p asap-planappliedbind_with_custom_cost_model_overrides_default_summary_choiceproves a customCostModelactually changes the bound summary (KLL -> DDSketch for the same query), not just that the parameter type-checks🤖 Generated with Claude Code