Repository navigation
A relabeled or renamed group key is priced at its old label's declared count #898
Description
Example
A source x declares 10,000 series and distinct_values_per_label: {"region": 4, "endpoint": 625}.
sum by (endpoint) (label_join(sum_over_time(x[15m]), "endpoint", "-", "region", "endpoint"))
- Today: the grouping is priced at 625 groups (
endpoint's declared count). - Actually: after
label_join,endpointholdsregion-endpoint, so there can be up to 4 x 625 = 2,500 groups. - Expected: no declared count applies to the rewritten key. The grouping falls back to
series_count(10,000) and the rows read.
The same happens in SQL: SELECT endpoint AS service, ... GROUP BY service is priced at service's 25, while there are up to 625 groups.
The examples come from a probe test during the review of #897. That code path existed before #897 and #897 did not change it.
Why it happens
group_count_bound (crates/plan-selection) looks up each key's per-label count by column name in the grouping's input schema. It never checks that the column still holds the source's values. #897 added unchanged_source_columns, a per-node trace of the columns that still hold one source row's labels unchanged. Only the label-set rule uses that trace; the per-label rule still matches on names.
Proposal
Add a second per-node set: the columns whose values are some source row's unchanged label, possibly paired across rows by a join or binary operator. The per-label sum stays a valid bound for those columns. Any other key gets no declared count, so it falls back to series_count and the rows read.
Acceptance
Pricing tests where the relabeled PromQL key and the renamed SQL column are priced at 10,000 groups, not 625 / 25. Existing per-label tests stay unchanged.
Activity