promql (histograms): Final decision about histogram related extensions of the language

[beorn7]

Before declaring native histograms a stable feature, we need to be reasonably confident that we won't need breaking changes in PromQL anymore.

Points to consider:

• Are we happy with the semantics and the functions introduced?
• What other functions do we still need to add and, perhaps more importantly, which existing functions and operators need to be extended to also support native histograms?
• Should we add new concepts (like a dot accessor, e.g. my_histogram.count)? (This could maybe done later as a non-breaking change, but at least we need an informed decision. Also, this would replace functions like histogram_count and histougram_sum, which we might not want to introduce into the stable feature set.)
• This should be accompanied by a proper design doc based on our experience so far and the brainstorming doc.

[beorn7]

We discussed this during the histogram sync. The current state here is essentially the following:

There are some more invasive ideas how to change PromQL to deal better with a mix of different sample types, but those are almost certainly too invasive to make it into v3 of Prometheus. So most likely we are happy with what we have. We just keep this open for a while in case somebody comes up with a brilliant new idea or we find some serious issues with the current approach. Otherwise, we'll just declare the current state as "good enough" when we get closer to the release date.

[jan--f]

Thanks for the update. I'll remove this from the Prometheus 3 project then.

[beorn7]

Hello from the bug scrub!

Native histograms won't be declared stable for the final v3 release, but in the hopefully not too far future.
When the time has come, we'll make the call asked for in this issue.

[beorn7]

With the spec being done and #13934 being done, I'm closing this.

There are a few edge cases not yet implemented (see TODOs in the spec) but these do not affect language fundamentals.