You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sort should not be removed when order by a + b where a and b are sorted as they can overflow and wrap #23902
Sort should not be removed when doing addition (and other operators that marked as kept ordering in binary expression code) on 2 sorted columns since they can overflow and the default behavior is wrapping so the sort will be broken
To Reproduce
Have this data file data/uint8_overflow_order.csv:
a,b1,12,3200,10255,10
and add this to order.slt for example
# Adding two ASC-ordered unsigned columns is only monotonically increasing while
# the sum does not overflow. `a + b` on UInt8 uses wrapping arithmetic, so the
# last row (255 + 10) wraps to 9 and breaks the ordering. A sort on the sum
# therefore must NOT be optimized away just because both inputs are ASC.
statement ok
set datafusion.execution.target_partitions = 1;
statement ok
CREATE EXTERNAL TABLE ordered_u8 (
a TINYINT UNSIGNED NOT NULL,
b TINYINT UNSIGNED NOT NULL
)
STORED AS CSV
LOCATION 'data/uint8_overflow_order.csv'
OPTIONS ('format.has_header' 'true')
WITH ORDER (a ASC)
WITH ORDER (b ASC);
query TT
EXPLAIN SELECT (a + b) AS result FROM ordered_u8 ORDER BY result ASC;
----
logical_plan
01)Sort: result ASC NULLS LAST
02)--Projection: ordered_u8.a + ordered_u8.b AS result
03)----TableScan: ordered_u8 projection=[a, b]
physical_plan DataSourceExec: file_groups={1 group: [[WORKSPACE_ROOT/datafusion/sqllogictest/data/uint8_overflow_order.csv]]}, projection=[a@0 + b@1 as result], file_type=csv, has_header=true
query I
SELECT (a + b) AS result FROM ordered_u8 ORDER BY result ASC;
----
2
5
210
9
statement ok
DROP TABLE ordered_u8;
# The SLT runner sets `target_partitions` to 4 instead of using the default, so
# reset it explicitly.
statement ok
set datafusion.execution.target_partitions = 4;
Expected behavior
The SortExec should not be removed as it break the ordering when overflow
changed the title [-]sort should not be removed when order by a + b where a asc and b asc as they can overflow and wrap[/-][+]sort should not be removed when order by a + b where a and b are sorted as they can overflow and wrap[/+]on Jul 25, 2026
I think technically the same applies to unary negation: -i64::MIN wraps to i64::MIN, so applying ORDER BY -a to a values like [-9223372036854775808, -5, 3] doesn't preserve the required ordering.
Activity
[-]sort should not be removed when order by a + b where a asc and b asc as they can overflow and wrap[/-][+]sort should not be removed when order by a + b where a and b are sorted as they can overflow and wrap[/+]fix: do not derive ordering for arithmetic that can overflow
buraksenn commentedon Jul 26, 2026
take
neilconway commentedon Jul 31, 2026
I think technically the same applies to unary negation:
-i64::MINwraps toi64::MIN, so applyingORDER BY -ato a values like[-9223372036854775808, -5, 3]doesn't preserve the required ordering.fix: do not derive ordering for arithmetic that can overflow (apache#…
fix: do not derive ordering for arithmetic that can overflow (apache#…