What is the problem the feature request solves?
This is #4288 sub-issue
These are the core infrastructure pieces that make TimeType columns usable in
real-world queries. Without them, any query that shuffles, sorts, or aggregates
a time column falls back to Spark.
Since TimeType is physically a fixed-width i64 (same as LongType/TimestampType),
all of these should be straightforward additions to existing type lists.
Describe the potential solution
Sort
File: spark/src/main/scala/org/apache/comet/serde/QueryPlanSerde.scala:833-843
supportedScalarSortElementType does not include TimeType. Add alongside
DateType | TimestampType | TimestampNTZType. The Rust sort implementation
already handles i64 types, so no native changes should be needed.
Min/Max aggregates
File: spark/src/main/scala/org/apache/comet/serde/aggregates.scala:742-751
minMaxDataTypeSupported has DateType | TimestampType but not TimeType.
Add it. The Rust min/max implementation works on any orderable Arrow type,
so Time64(Nanosecond) should work without native changes.
Additional context
No response
What is the problem the feature request solves?
This is #4288 sub-issue
These are the core infrastructure pieces that make TimeType columns usable in
real-world queries. Without them, any query that shuffles, sorts, or aggregates
a time column falls back to Spark.
Since TimeType is physically a fixed-width i64 (same as LongType/TimestampType),
all of these should be straightforward additions to existing type lists.
Describe the potential solution
Sort
File: spark/src/main/scala/org/apache/comet/serde/QueryPlanSerde.scala:833-843
supportedScalarSortElementType does not include TimeType. Add alongside
DateType | TimestampType | TimestampNTZType. The Rust sort implementation
already handles i64 types, so no native changes should be needed.
Min/Max aggregates
File: spark/src/main/scala/org/apache/comet/serde/aggregates.scala:742-751
minMaxDataTypeSupported has DateType | TimestampType but not TimeType.
Add it. The Rust min/max implementation works on any orderable Arrow type,
so Time64(Nanosecond) should work without native changes.
Additional context
No response