[RishavTiwari25]

Which issue does this PR close?

• Closes Rewriting SUM(x + c) to SUM(x) + c * COUNT(x) changes the result for floating point x #26223.

Rationale for this change

When a query has two or more SUM(x + <literal>) aggregates over the same x, the optimizer rewrites them into SUM(x) + <literal> * COUNT(x) so that only two aggregates are computed. For integers that is exact, but floating point addition is not associative, so for Float64 the rewritten query can return a different value than the same aggregate on its own:

SELECT sum(x + 1.0) FROM (VALUES (1e16), (1.0), (-1e16)) AS t(x);
-- 2.0
SELECT sum(x + 1.0), sum(x + 2.0) FROM (VALUES (1e16), (1.0), (-1e16)) AS t(x);
-- 4.0 | 7.0   (2.0 | 7.0 when each aggregate is computed on its own)

What changes are included in this PR?

• rewrite_multiple_linear_aggregates now takes the aggregate's input schema and skips candidates whose argument or literal is a floating point type, so those aggregates are computed as written. Integer aggregates are rewritten as before.
• The guard lives in the optimizer rather than in Sum::simplify_expr_op_literal because the inexactness comes from floating point arithmetic, not from SUM itself, and because fix: plan and run repeated SUM(x + literal) on decimals and intervals #25966 is changing that function for decimals and intervals; keeping this change separate avoids conflicts, and I am happy to rebase on whichever lands first.

What is the testing strategy for this PR?

New sqllogictest cases in aggregates_simplify.slt cover a DOUBLE column with float literals, a DOUBLE column with integer literals, and an integer column with float literals, checking both the results and that the EXPLAIN plan keeps the original aggregates. The existing integer cases in the same file still show the rewrite.

Are there any user-facing changes?

Queries with several SUM(<float> + <literal>) aggregates now return the same values as the individual aggregates. They no longer get the shared SUM/COUNT rewrite, so they compute one aggregate per expression, as they did before the rewrite was introduced.

I used an AI coding assistant while working on this change; I have read the diff and the tests and can walk through them.

[RishavTiwari25]

@alamb could you trigger CI on this one when you have a moment? It is my first PR here. Thanks!

[alamb]

Thank you @RishavTiwari25. However, I question is this is a bug, see #26223 (comment)

[alamb]

As mentioned, I don't think this is a bug

[RishavTiwari25]

Closing per the discussion on #26223: this is floating point reassociation rather than a bug, and the rewritten form is actually the more accurate one in the reported example.