Summary
The bgp_jan2024_workload 200-query corpus (#219) has 3 occurrences of ClickHouse's argMax(arg, val) — "return arg's value from the row where val is maximal" — which currently fails to lower. Unlike #230's scalar-function gaps, this isn't a planner-registration problem to route around: there's no existing AggIntent variant (crates/types/src/pre_asap/agg_intent.rs) that can represent it at all.
Why this doesn't fit the existing shape
AggIntent::Max { col } reduces one column to its own extreme value. argMax(arg, val) is different in kind: it returns a different column's value, selected by which row maximizes a second column — a two-column, row-selecting aggregate, not a single-column reduction. None of the existing variants (Min/Max/Sum/Avg/Quantile/TopK/Cardinality/...) have this shape.
Two ways to represent it
- A proper new core
AggIntent::ArgMax { arg_col, val_col } variant (and presumably ArgMin alongside it, and their by-group/schema-derivation logic in aggregate_output_schema) — if this is common enough across dialects/deployment models to earn a first-class spot.
AggIntent::Extension — the crate's own deliberate escape hatch for exactly this situation ("a deployment model that needs something core doesn't have carries it here, tagged by its own kind string... core only grows for intents ≥2 deployment models actually use," per its doc comment). Core would treat it opaquely (no schema derivation, no per-series/data-model logic) until/unless a second use case justifies promoting it to (1).
Scope of this issue
Settle which of the two directions to take (or gather more evidence — e.g. does any PromQL-side or another SQL dialect's workload also want arg-max/arg-min, which would tip the scale toward a first-class variant per the crate's own "≥2 deployment models" bar?). Not asking for an implementation yet.
Related
Summary
The
bgp_jan2024_workload200-query corpus (#219) has 3 occurrences of ClickHouse'sargMax(arg, val)— "returnarg's value from the row wherevalis maximal" — which currently fails to lower. Unlike #230's scalar-function gaps, this isn't a planner-registration problem to route around: there's no existingAggIntentvariant (crates/types/src/pre_asap/agg_intent.rs) that can represent it at all.Why this doesn't fit the existing shape
AggIntent::Max { col }reduces one column to its own extreme value.argMax(arg, val)is different in kind: it returns a different column's value, selected by which row maximizes a second column — a two-column, row-selecting aggregate, not a single-column reduction. None of the existing variants (Min/Max/Sum/Avg/Quantile/TopK/Cardinality/...) have this shape.Two ways to represent it
AggIntent::ArgMax { arg_col, val_col }variant (and presumablyArgMinalongside it, and their by-group/schema-derivation logic inaggregate_output_schema) — if this is common enough across dialects/deployment models to earn a first-class spot.AggIntent::Extension— the crate's own deliberate escape hatch for exactly this situation ("a deployment model that needs something core doesn't have carries it here, tagged by its ownkindstring... core only grows for intents ≥2 deployment models actually use," per its doc comment). Core would treat it opaquely (no schema derivation, no per-series/data-model logic) until/unless a second use case justifies promoting it to (1).Scope of this issue
Settle which of the two directions to take (or gather more evidence — e.g. does any PromQL-side or another SQL dialect's workload also want arg-max/arg-min, which would tip the scale toward a first-class variant per the crate's own "≥2 deployment models" bar?). Not asking for an implementation yet.
Related
bgp_jan2024_workloadcorpus test, where this gap was foundcrates/types/src/pre_asap/agg_intent.rs—AggIntent,AggIntent::Extension