PromQL: Multiplication by 1 creates additional floating point errors (but should be a no-op) about prometheus HOT 6 OPEN

It's not so much the grouping or the join that creates these artifacts, but the multiplication. At least I can create the same "noisy" heatmap by multiplying with a 1 literal.

I'm confused why this is happening, as multiplication by 1 should be a no-op (and with the query linked above, it should be guaranteed that an actual 1.0 float arrives in the engine).

from prometheus.

compare (prometheus_http_request_duration_seconds_bucket)

• with join
• without join

from prometheus.

Fundamentally, I would say there must be a different code path in the PromQL engine for "sum the result of a function call" and "sum the result of a bin-op", but from the top of my head, I cannot imagine how that would happen.

from prometheus.

One possible workaround is to use something like round(_, 0.00001). Does this give the same result as the unmultiplied query?

compare:

• round(sum by (le) (increase(prometheus_http_request_duration_seconds_bucket[1m]) * 1), 0.00001) link
• sum by (le) (increase(prometheus_http_request_duration_seconds_bucket[1m])) link

from prometheus.

We discussed on the chat-system-that-shall-not-be-named. I guess the most likely reason for this is what @bboreham said there: "At a high level, it’s likely that each new expression changes the order of evaluation, which will give different results since addition is non-commutative."

from prometheus.

Just wanted to highlight #14074, which I think could improve the optics, at some CPU cost.
I didn't understand this issue enough to make a test case.

from prometheus.