morrySnow opened a new pull request, #67801: URL: https://github.com/apache/doris/pull/67801
## Problem When a query contains multiple aggregates such as SUM(x + 1.0) and SUM(x + 2.0), the optimizer reassociates them into SUM(x) plus COUNT(x) times each literal. For floating-point inputs this changes IEEE-754 rounding from per-row addition to post-aggregation addition and can return a different result. ## Root cause SumLiteralRewrite accepted both integer and floating-point literals, but did not require the analyzed input expression and arithmetic result to be integer types. The transformation is not semantics-preserving for floating-point arithmetic. ## Reproduction With DOUBLE values 1e16 and -1e16, the two original aggregates produce 0 and 4. Before this change, the rewritten plan produced 2 and 4 and exposed COUNT in the aggregate plan. ## Fix Restrict the reassociation to expressions whose analyzed child, non-literal operand, and literal operand are all integer-like. Floating-point and decimal expressions remain unchanged. Existing widening integer-cast handling is preserved. Integer overflow behavior is intentionally unchanged. ## Tests - Added unit coverage for integer, float, double, decimal, and mixed operand types. - Added a regression case for the floating-point rounding reproduction and verified that its plan is not rewritten. - Verified that integer aggregates still use the optimization. - Ran the focused FE unit test, the full FE build with checkstyle, and the sumRewrite regression suite. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
