Jefffrey commented on code in PR #20032:
URL: https://github.com/apache/datafusion/pull/20032#discussion_r2740577743
##########
datafusion/functions/src/string/ltrim.rs:
##########
@@ -119,18 +119,87 @@ impl ScalarUDFImpl for LtrimFunc {
}
fn invoke_with_args(&self, args: ScalarFunctionArgs) ->
Result<ColumnarValue> {
- match args.args[0].data_type() {
+ let return_type = args.return_field.data_type();
+ let number_rows = args.number_rows;
+ let args = args.args;
+
+ // If any argument is a scalar NULL, the output is NULL for all rows
+ if args
+ .iter()
+ .any(|v| matches!(v, ColumnarValue::Scalar(s) if s.is_null()))
+ {
+ if args.iter().any(|v| matches!(v, ColumnarValue::Array(_))) {
+ return Ok(ColumnarValue::Array(arrow::array::new_null_array(
+ return_type,
+ number_rows,
+ )));
+ }
+ return
Ok(ColumnarValue::Scalar(ScalarValue::try_from(return_type)?));
+ }
+
+ // Scalar fast path
+ if args.iter().all(|v| matches!(v, ColumnarValue::Scalar(_))) {
Review Comment:
Can we identify in this PR which changes actually lead to speedup? If its
the null handling or the new scalar fast path? I'm hesistant on this PR since
though we have small gains, the scalar fast path in particular is confusing
since it tacks on a new scalar fast path when the existing fast path still
remains (but would remain unused?)
--
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]
