Repository navigation
Optimizer: enforce accuracy_sla and latency_sla in candidate eligibility #757
Description
Activity
- linked a pull request that will close this issuefeat(planner): enforce candidate SLA eligibility #781
on Oct 5, 2026 This was generated by AI during triage.
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.This was generated by AI during triage.
#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.
Problem
ControllerOptions.accuracy_slaandlatency_slaare 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):
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.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