Repository navigation
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #24502 +/- ##
==========================================
- Coverage 82.69% 82.68% -0.01%
==========================================
Files 1147 1147
Lines 447204 447300 +96
Branches 447204 447300 +96
==========================================
+ Hits 369793 369865 +72
- Misses 55002 55014 +12
- Partials 22409 22421 +12 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
cc @Jefffrey for review when you get a moment |
|
run benchmark array_sort |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing jsod/array-sort-options-08-19-26 (c9881ce) to bd86190 (merge-base) diff Run configurationrun benchmark array_sortCPU Details (lscpu)Details
Resource Usagearray_sort — base (merge-base)
array_sort — branch
File an issue against this benchmark runner |
Jefffrey
left a comment
There was a problem hiding this comment.
impacts on benchmarks are unfortunate; we could probably tune things a bit to optimize, but perhaps the best way would be to have a separate scalar & array path. i.e. have a fast scalar path for when we have scalar inputs for sort order & nulls order, otherwise fallback to slower array path when all inputs are arrays. though this likely we increase required code 🙁
| let row_count = list_array.len(); | ||
| let list_nulls = list_array.nulls(); | ||
| let offsets = list_array.offsets(); | ||
| let mut list_validity = BooleanBufferBuilder::new(row_count); |
There was a problem hiding this comment.
instead of using a builder here we can consider using something like NullBuffer::union to construct the null buffer upfront from all the input arrays
Which issue does this PR close?
array_sortdoesnt respect array inputs for sort order/nulls first #24132Rationale for this change
array_sortnow evaluates its optionalorderandnulls_orderarguments per row instead of reading only the first row of each option column.Previously, queries like this would use the first row's option value for the whole batch:
So if row 1 used 'asc' and row 2 used 'desc', row 2 could still be sorted ascending.
This PR keeps the existing primitive and non-primitive sorting paths, but threads the option arrays through the sort logic so each output row uses that row's own options.
What changes are included in this PR?
Sort order can vary per row
Before this PR, all rows used the first row's 'asc' option:
Now each row uses its own option:
NULL option values are handled per row
Before this PR, the NULL and 'DESC' rows still used the first row's 'ASC' option:
Now the NULL option only affects its own row:
Null placement can vary per row
Before this PR, later rows could incorrectly reuse the first row's sort options.
Now each row gets the correct ordering:
Additional coverage
This also covers:
• primitive arrays without element nulls
• primitive arrays with element nulls
• non-primitive arrays, such as strings
• NULL order arguments
• NULL nulls_order arguments
• preserving valid empty lists as []
Are these changes tested?
Are there any user-facing changes?
Just the bug fixes described.