0lai0 commented on code in PR #4987:
URL: https://github.com/apache/datafusion-comet/pull/4987#discussion_r4423916726
##########
spark/src/main/scala/org/apache/spark/sql/comet/CometWindowExec.scala:
##########
@@ -393,30 +393,30 @@ object CometWindowExec extends
CometOperatorSerde[WindowExec] {
}
}
- // Comet's native window planner ships RANGE frame offsets as
- // ScalarValue::Int64, which the DECIMAL comparator can't handle: Spark
- // decimal arithmetic widens precision on +/-, so the computed boundary
- // (e.g. Decimal(11,0)) doesn't match the current value's precision
- // (e.g. Decimal(10,0)) and the comparator fails with "Uncomparable
- // values". Fall back for DECIMAL until the native side normalizes
- // precision. DATE is now handled natively by wrapping the offset as
- // IntervalDayTime in the planner. UNBOUNDED / CURRENT ROW bounds don't
- // evaluate the offending arithmetic and stay native regardless.
+ // DataFusion computes a RANGE frame bound as `current +/- offset` and
treats
+ // a bound that overflows as the edge of the partition, which also takes in
+ // NULL keys sorted at that edge. Spark's bound never overflows that way,
so
+ // fall back for the offsets that can overflow. UNBOUNDED / CURRENT ROW
+ // bounds skip the arithmetic and stay native.
//
// For DATE, Spark computes the bound with DateAdd, an Int addition that
- // wraps silently on overflow, while DataFusion treats an overflowing bound
- // as the partition edge. Over dates in Spark's supported range the two
only
- // disagree when the offset is large enough to wrap, so fall back for those
- // offsets. https://github.com/apache/datafusion-comet/issues/5022
+ // wraps silently on overflow. Over dates in Spark's supported range the
two
+ // only disagree when the offset is large enough to wrap, so fall back for
+ // those offsets.
+ //
+ // For DECIMAL, Spark's DecimalAddNoOverflowCheck keeps the exact bound,
+ // while DataFusion adds in Decimal128 and overflows past i128.
+ // https://github.com/apache/datafusion-comet/issues/5022
f match {
case SpecifiedWindowFrame(RangeFrame, lb, ub)
if !lb.isInstanceOf[SpecialFrameBoundary] ||
!ub.isInstanceOf[SpecialFrameBoundary] =>
windowExpr.windowSpec.orderSpec.headOption.map(_.dataType) match {
- case Some(_: DecimalType) =>
+ case Some(dt: DecimalType) if !Seq(lb,
ub).forall(isDecimalRangeOffsetSafe(_, dt)) =>
Review Comment:
Yes, thanks. A negative literal like `-10000000000000000000000000000000001`
is parsed exactly (`MINUS? INTEGER_VALUE`), and an ascending `ORDER BY` adds it
unchanged, but `Decimal.abs` negates it and rounds to 34 digits on Scala 2.13.
`rangeBoundLiteral` now uses `Decimal(d.toJavaBigDecimal.abs, d.precision,
d.scale)` as you suggested. The new test covers `-N FOLLOWING AND CURRENT ROW`
and `CURRENT ROW AND -N PRECEDING`; with `d.abs` it fails (the `N` row counts 2
natively against Spark's 3), and with the exact absolute value it matches Spark.
--
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]
