mbutrovich commented on code in PR #5044:
URL: https://github.com/apache/datafusion-comet/pull/5044#discussion_r3691873711
##########
native/spark-expr/src/math_funcs/internal/decimal_rescale_check.rs:
##########
@@ -199,11 +199,10 @@ impl PhysicalExpr for DecimalRescaleCheckOverflow {
let result = if !fail_on_error &&
result.values().contains(&i128::MAX) {
Review Comment:
`decimal_rescale_check.rs:200` still runs
`result.values().contains(&i128::MAX)` on every batch. In the common
no-overflow case that is a full read of the output buffer, the same cost this
PR removes from `WideDecimalBinaryExpr` by tracking overflow with a
`Cell<bool>` inside the `try_binary` closure instead of scanning for the
sentinel afterward.
`DecimalRescaleCheckOverflow::evaluate` has the same sentinel-then-mask
shape, just built on `try_unary` instead of `try_binary`. The same
closure-capture technique applies there without changes to the surrounding
logic. Right now this PR updates the comment on
`decimal_rescale_check.rs:201-205` to admit the scan still happens, but leaves
the scan itself in place, so one of the two call sites gets the actual fix and
the other gets a note explaining why it still pays the cost.
Could you either apply the same `Cell<bool>` guard to
`decimal_rescale_check.rs`, or open a follow-up issue for it so the asymmetry
is tracked rather than left implicit in a comment? If it is deliberately out of
scope for this PR, a one-line note here (or in the PR description) saying so
would help.
--
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]
