"Aggressive" optimizations mode

[GiedriusS]

There are some optimizations that are not done in Prometheus PromQL engine due to backward compatibility. However, those use cases that they are trying not to break only really matter to a few percent of the users. Thus, I suggest adding some kind of new parameter to the engine which would add an optimization pass to the given PromQL expression. The results/behavior wouldn't be strictly compatible with the original PromQL but I think that doesn't matter to Thanos/Cortex/... users anyway.

Some candidates:

• Propagate label selectors across binary ops prometheus/prometheus#8053
• ... more?

[fpetkovski]

This makes sense. I did not understand why propagating labels across bin-ops is a breaking change though. We might want to document this well once we implement it.

[GiedriusS]

Because apparently there are "storages" which return data that does not strictly match the given matchers 😄 however, I think it's probably such a rare use-case that we could enable such optimizations by default.

[fpetkovski]

Makes sense to have this enabled by default in Thanos at least. It shouldn't be too hard to implement, we just need to handle the vector matching in cases like:
metric_1 / on(label_1) group_left metric_2{label_2="value_2"}

[bwplotka]

Happy to configure different optimizers in future. But it should case driven. I can't see anything "too aggressive" so far 🤔