Background
PR #404 added support for UnivMon (Universal Monitoring) being able to serve multiple metrics — specifically L2 norm, distinct count, and entropy — from a single sketch. In the current design this multi-metric capability is bundled into MaintainedPopulationStrategy alongside the topk/quantile sharing logic (see companion issue).
Problem
UnivMon's ability to answer several different metrics is really just another synopsis option for those metrics, so it belongs in the sketch strategy (the candidate-generation stage that maps a query intent to the set of synopses that can satisfy it), not in a separate strategy.
The sketch strategy already works by enumerating candidate synopses per intent. UnivMon fits that model directly:
distinct intent -> [HLL, UnivMon]
entropy intent -> [UnivMon, CS]
Once these candidates exist, downstream stages handle the rest:
CSE (see companion issue) can recognize that a single UnivMon instance covers both the distinct and entropy intents, and merge them structurally — the sharing opportunity is visible before costing.
The cost model then compares the full candidate set (e.g. the 4 candidates from the example above: HLL, UnivMon-for-distinct, UnivMon-for-entropy, CS) and finds that a single shared UnivMon has the lowest total cost.
Proposal
Move UnivMon's L2 / distinct / entropy support out of MaintainedPopulationStrategy and express it as candidate-generation rules within the sketch strategy: each supported metric intent lists UnivMon among its candidate synopses. The sharing/merging across metrics is then handled by CSE, and final selection by the cost model — no dedicated strategy needed.
Background
PR #404 added support for UnivMon (Universal Monitoring) being able to serve multiple metrics — specifically L2 norm, distinct count, and entropy — from a single sketch. In the current design this multi-metric capability is bundled into MaintainedPopulationStrategy alongside the topk/quantile sharing logic (see companion issue).
Problem
UnivMon's ability to answer several different metrics is really just another synopsis option for those metrics, so it belongs in the sketch strategy (the candidate-generation stage that maps a query intent to the set of synopses that can satisfy it), not in a separate strategy.
The sketch strategy already works by enumerating candidate synopses per intent. UnivMon fits that model directly:
distinct intent -> [HLL, UnivMon]
entropy intent -> [UnivMon, CS]
Once these candidates exist, downstream stages handle the rest:
CSE (see companion issue) can recognize that a single UnivMon instance covers both the distinct and entropy intents, and merge them structurally — the sharing opportunity is visible before costing.
The cost model then compares the full candidate set (e.g. the 4 candidates from the example above: HLL, UnivMon-for-distinct, UnivMon-for-entropy, CS) and finds that a single shared UnivMon has the lowest total cost.
Proposal
Move UnivMon's L2 / distinct / entropy support out of MaintainedPopulationStrategy and express it as candidate-generation rules within the sketch strategy: each supported metric intent lists UnivMon among its candidate synopses. The sharing/merging across metrics is then handled by CSE, and final selection by the cost model — no dedicated strategy needed.