You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Planner: error models and parameter lists for Hydra (and other unsized families), so Pass 1 can offer them #1228
topk(10, sum by (job) (rate(http_requests_total[5m]))) evaluated for every one of 2,000 job values could share one Hydra-CMS structure (one sketch per subpopulation, shared rows and columns) instead of 2,000 separate Count-Min sketches. The executor can build and query Hydra structures, but the planner never offers one: it has no error model for Hydra, so it cannot say what (ε, δ) a given Hydra size guarantees for a subpopulation's estimate, and it cannot check the query's accuracy target.
Where this shows today
Pass 1 offers only the families in FAMILY_PREFERENCE; estimators::size_params treats HydraCms, HydraCountSketch, HydraKll, HydraHll and HydraUnivMon as unreachable! (crates/accuracy/src/estimators/mod.rs).
local_guarantee returns no guarantee for a Hydra state; a Pass 1 test asserts this.
For each Hydra kind (and, separately, each other family above that should be offered):
Error model: the guarantee (metric, ε, δ) of one subpopulation's estimate as a function of the Hydra sizes (width, depth, shared_rows, shared_columns, and the per-subpopulation sketch's own θ), for each statistic it answers. Absolute ε for Hydra-CMS was the starting point discussed earlier.
Predefined list:parameter_list(family) entries for that family, and the per-family comparison satisfies uses (θ_u ⪰ floor).
Error propagation: the metric each readout reports, so the metric rule and constraint (K) apply (concepts doc, Section 4).
Pass 1 offering the family once 1–3 exist.
Scope
Known limitation of the #1207 refactor; future work, not part of #1207's merge unit.
Activity
docs(concepts): note the empty parameter lists of unsized families (#…