mirror of
https://github.com/GreptimeTeam/greptimedb.git
synced 2026-11-14 06:46:56 +00:00
I hereby agree to the terms of the [GreptimeDB CLA](https://github.com/GreptimeTeam/.github/blob/main/CLA.md). ## Refer to a related PR or issue link (optional) Native tree operator wiring, aggregate category (`count_values`, #25). Stacked on #9853 → #9852 → #9851 → #9850; its own change is the last commit. Draft until those merge. ## What's changed and what's your intention? `count_values(label, v)` runs natively as `BoundSelect::CountValues { label, group }` through `aggregate::count_values`. - **Why this node.** `count_values` writes one label set per distinct value, which #9833 leaves out of `AggregateKind` as a different shape. It reads the whole vector at a point, which is what the select node does. - **Output.** Groups are keyed by their final label set, so each result label set is one series and the node does not mark its output as holding pieces. Input pieces of one label set hold disjoint points, so their counts add. - **Memory.** The estimate charges a group per row, since a gauge with distinct values makes about one group per sample: the group's label set twice with the value label, its counts and its result series. Not here: compiling `count_values`, which is an aggregate expression and goes through #9833. Before it is compiled, it needs a decision on native histogram input. Prometheus counts histograms by their string form; the kernel refuses them with `NotImplemented`. Until the kernel covers them, the compiler has to refuse such input. ### Tests - Runtime: values shared across series are counted per point, including a series delivered in two chunks. - Display: the `count_values` line. ## PR Checklist Please convert it to a draft if some of the following conditions are not met. - [x] I have written the necessary rustdoc comments. - [x] I have added the necessary unit tests and integration tests. - [ ] This PR requires documentation updates. - [x] API changes are backward compatible. - [x] Schema or data changes are backward compatible. - [ ] This PR needs to be backported to release branches, and I have added the `backport-<target>` labels (e.g. `backport-v1.3` targets `release/v1.3`).