tustvold commented on code in PR #6906:
URL: https://github.com/apache/arrow-rs/pull/6906#discussion_r1894461220
##########
arrow-arith/src/numeric.rs:
##########
@@ -550,6 +568,21 @@ date!(Date64Type);
trait IntervalOp: ArrowPrimitiveType {
fn add(left: Self::Native, right: Self::Native) -> Result<Self::Native,
ArrowError>;
fn sub(left: Self::Native, right: Self::Native) -> Result<Self::Native,
ArrowError>;
+ fn mul_int(left: Self::Native, right: i32) -> Result<Self::Native,
ArrowError>;
+ fn mul_float(left: Self::Native, right: f64) -> Result<Self::Native,
ArrowError>;
+ fn div_int(left: Self::Native, right: i32) -> Result<Self::Native,
ArrowError>;
+ fn div_float(left: Self::Native, right: f64) -> Result<Self::Native,
ArrowError>;
Review Comment:
It's a sound idea in principle, and this sort of approach to avoiding
codegen is something I would generally advocate for, however, I don't think it
works in this case.
In particular we don't support arithmetic operations between heterogeneous
primitive types, e.g. int32 * float64, instead leaving such coercion to to
query planners which are better placed to do this. The result is that we would
effectively need the query engines to do this explosion for us, in order for
things like `interval * f64` to work.
Even discounting this, the performance characteristics of such an approach
would be unfortunate, at that point you'd be better off using a StructArray
--
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]
