Björn Rabenstein

We have discussed this at the dev-summit. The consensus reached there is the following: > Starting with Prometheus 3.0, any querier implementation MUST return something that matches the selectors sent...

In more detail: The idea is that we can do optimizations relying on selectors returning matching results starting from v3.0.0. Should relevant use cases show up that are now broken...

@LeviHarrison : My understanding is that the mandate we have agreed upon now _unlocks_ what has been proposed in #8053. So v3.0 makes it possible to work on it, while...

To clarify: The optimization described in #8053 hasn't been implemented at all. In the discussion, the concern was brought up that this optimization, should we implement it, would break with...

Picking this up as part of our bug scrub… @darshanime are you still up to working on this? What do you think about @codesome's comment? Test coverage is also an...

@codesome maybe you can help us out here?

BTW: The sub-queries are much harder to reason with. I cannot really explain the precise values in the tests. (Perhaps @codesome can, but he has still very limited availability.)

In any case, I'll create a follow-up PR where I had histograms to the tests, because reviewing this PR showed me that they are still missing.

Thanks for your comments. I'll look into them once I find time. (But I have to say that I feel heavily underqualified for this review. I guess we need help...

Note to reviewers: https://github.com/prometheus/prometheus/pull/10369 is the PR that implemented the feature. This might be helpful to find out what the intended meaning of the stats fields is.