viirya opened a new pull request, #5630:
URL: https://github.com/apache/datafusion-comet/pull/5630
## Which issue does this PR close?
Closes #5629.
## Rationale for this change
`spark_map_sort` builds its `take` indices only for the maps that are
visible, so
the sorted entries it produces are indexed from zero. It then passed the
*input*
offsets straight to `MapArray::try_new`:
```rust
let sorted_entries = take(maps_arg_entries, &indices, None)?;
...
MapArray::try_new(
Arc::clone(map_field),
maps_arg.offsets().clone(), // original offsets, not rebased
sorted_map_struct.clone(),
...
)
```
A sliced `MapArray` keeps its original entry offsets, so for two two-entry
maps
sliced to drop the first, the offsets are `[2, 4]` against 2 taken entries
and Arrow
rejects the result with `Max offset of 4 exceeds length of entries 2`.
A native OFFSET is enough to produce that slice (DataFusion's limit uses
`batch.slice(skip, ...)`), and Spark 4.0+ inserts `MapSort` on its own, so
this fails
a real query today — a group-by on a map column below an OFFSET, with no
explicit
`mapsort` call and no configuration changes.
## What changes are included in this PR?
- `map_sort.rs`: rebuild the output offsets from the per-map lengths rather
than
reusing the input offsets. Empty maps still contribute an offset entry, so
a map
array containing empty maps keeps the right offset count (the previous
`continue`
skipped the whole iteration).
## How are these changes tested?
- New Rust unit test `test_sliced_map_offsets_are_rebased`: slices a two-map
array to
drop the first map, asserts the slice really does keep the original
offsets, and
checks the sorted keys and values. `cargo test -p
datafusion-comet-spark-expr
map_sort` passes 9 tests.
- New end-to-end test in `CometMapExpressionSuite`: a group-by on a map
column below
`LIMIT ... OFFSET ...`, compared against Spark. `CometMapExpressionSuite`
passes 23
tests.
I checked that both tests actually guard the fix by reverting the offset
rebase and
rebuilding: the Rust test and the end-to-end test both fail, with the Arrow
error
above.
## Additional context
Found by @sunchao while reviewing #5567, which admits nested types as native
shuffle
hash partitioning keys and would add `InsertMapSortInRepartitionExpressions`
as a
second route into this code. This fix is independent of that PR — the
group-by path
reproduces on current `main` — so it is split out here. Once this merges I
will add
the repartition-on-map coverage to #5567, where that path becomes reachable.
--
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]
