Repository navigation
Optimizer: enforce accuracy_sla and latency_sla in candidate eligibility #757
Description
Problem
ControllerOptions.accuracy_sla and latency_sla are parsed but unused; nothing stops the optimizer picking an under-provisioned sketch.
Change
Enforce both as candidate eligibility filters (per item, see the AQE-item issue):
- Accuracy: measured
AtomicCostEntry.query_accuracy[metric(family)]vsaccuracy_sla, via a fixed per-family metric table in the planner (e.g. CMS →relative_error_mean, KLL →mean_rank_err, HLL →relative_error, CMS-heap →1 − recall_at_k).0.0= unconstrained. Missing measurement = ineligible. Exact accumulators always pass. - Latency: estimated query CPU seconds (
groups × (query + (n−1)·merge), or the Subtract form) ≤latency_sla(seconds).0.0= unconstrained.
Known gaps (tracked separately): quantile rank error ≠ value error; accuracy is measured on a single instance, not after merging.
Refs #526.
Part of #753.
🤖 Generated with Claude Code
Activity
milindsrivastava1997 commentedon Oct 5, 2026
The CMS portion of this issue is blocked by #762.
relative_error_meanis not a valid normalized SLA metric for the benchmarked CMS output, and whether CMS should remain eligible for SUM/COUNT is being decided with the aggregation capability mapping there. Once #762 establishes the serving families and their accuracy metrics, this issue can apply the resulting eligibility policy.milindsrivastava1997 commentedon Oct 5, 2026
#757 is also blocked by #787. Restricting CMS to top-k requires deployable replacement summaries for SUM and COUNT; until the data-plane and query engine support those summaries, enforcing the revised capability mapping would make those query paths unservable.