Tracking issue for "degree of freedom" we should add when converting from L3 to L4

[milindsrivastava1997]

It's possible that some of these are out of scope here, and should be accounted for in downstream artifacts (ASAPCollector, ASAPQuery, asap-fusion)

Degrees of freedom

• Different sketches (KLL vs DDSketch)
• Different parameters for same sketch
• Hydra vs sketch-per-subpopulation (exact treatment of subpopulations)
• Single-level Hydra or multi-level Hydra
• Sliding window vs tumbling window computation of sketches
• Sliding window sketches vs exact treatment of time
• AHA vs treating hierarchical subpopulations independently

Query properties

Is query:

• Summmarizable?
• Collapsable? (e.g. when sum by (cpu) (sum_over_time(data[5m]) is translated to SQL, it doesn't need to be a nested query - it can be collapsed into a single SUM with GROUP BY cpu)

Summary properties

Is summary:

• Mergeable?
• Subpopulation aware?
• Subtractable?
• Able to delete an item?

[milindsrivastava1997]

@zzylol @Selvomega FYI

[zzylol]

Related open work

• Candidate search infrastructure is tracked by asap-aware-mapping: Cascades/Volcano-style candidate-plan search engine over ReplacementStrategy #252.
• Nested exact and approximate composition are Compose exact operators with summary plans across explicit update/readout boundaries #171 and Propagate end-to-end accuracy guarantees for approximate-over-approximate plans #172; structured summary kinds are Multi-dimensional / structured summary kinds (e.g. QTree-style range trees, Hydra-style sketch composition) #173.
• Evaluate AHA-style sparse-subpopulation strategy vs. maintaining full hierarchical sub-population summaries #288 evaluates the AHA-style sparse-subpopulation degree of freedom.
• Overall optimization applicability remains tracked by Add logic to detect which optimizations are applicable to a query workload #33.