Repository navigation
fix: plan and run repeated SUM(x + literal) on decimals and intervals - #25966
Merged
adriangb merged 2 commits intoOct 23, 2026
Merged
Conversation
Signed-off-by: 1fanwang <1fannnw@gmail.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #25966 +/- ##
==========================================
- Coverage 82.59% 82.59% -0.01%
==========================================
Files 1145 1145
Lines 444096 444099 +3
Branches 444096 444099 +3
==========================================
- Hits 366806 366803 -3
- Misses 55021 55024 +3
- Partials 22269 22272 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
bvolpato
approved these changes
Oct 11, 2026
bvolpato
left a comment
Contributor
There was a problem hiding this comment.
LGTM, thanks for fixing this. Rechecked decimal coercion and result types, including integer offsets, nulls and empty inputs. The decimal and interval regressions pass locally and fail with the guard removed.
This was referenced Oct 12, 2026
adriangb
approved these changes
Oct 17, 2026
Signed-off-by: 1fanwang <1fannnw@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Which issue does this PR close?
SUM(expr + literal)aggregates fail or change result type #25943.Rationale for this change
A query with two or more SUM(expr + literal) aggregates over the same interval or decimal expression fails or changes its result. Two interval sums fail to plan with "Invalid interval arithmetic operation: Interval(MonthDayNano) * Interval(MonthDayNano)". Two decimal sums can fail at execution with "12.0 is too large to store in a Decimal128 of precision 2", or return a different decimal type than the same SUM written alone. Each aggregate works when it is the only one in the query.
The cause is the ClickBench Q29 optimization from #20749, which only fires when several such aggregates share an expression. It rewrites each SUM(expr + literal) into SUM(expr) + literal * COUNT(expr), with COUNT cast to the literal's type. That cast is not valid for intervals, and for decimals it can overflow the literal's narrow type or change the result type.
What changes are included in this PR?
The rewrite now applies only when the literal is an integer or floating-point value. Interval and decimal sums are left as written, so they plan, run and keep the result type they have on their own. Integer literals, the ClickBench Q29 case, are rewritten as before. Making the rewritten expression reproduce SUM's decimal result type exactly would be another option, but skipping the rewrite for these types is the smaller change.
What is the testing strategy for this PR?
New cases in aggregates_simplify.slt run two interval sums, two decimal sums that overflowed, and two decimal sums whose type changed, next to the existing rewrite tests.
Testing Done
The issue's queries in datafusion-cli, built with cargo build --profile ci -p datafusion-cli on main (416002a) and on this branch:
On main, a single interval SUM works but two fail to plan, two decimal sums fail at execution, and the decimal result type changes from Decimal128(24, 5) to Decimal128(29, 10) when a second SUM is added:
On this branch, every query runs and the multi-SUM results match the single SUM's values and types:
Reproducer source: sum-literals.sql
Are there any user-facing changes?
Yes. Queries with several SUM(expr + literal) aggregates over interval or decimal values now plan, run and keep the single-aggregate result type. No API changes.