fix(compute/exec): do not carry a cached null count across ArraySpan.SetSlice - #1306
Open
singhpratech wants to merge 2 commits into
Open
singhpratech wants to merge 2 commits into
singhpratech wants to merge 2 commits into
Conversation
…SetSlice SetSlice kept the cached null count for the new slice when it was 0 or equal to the old length. That is only right while the count describes the whole span; a kernel that calls UpdateNullCount on the span the executor reuses stores the slice's count, and the next SetSlice then treats the following slice as all valid or all null. and_kleene and or_kleene return false where the answer is null once ExecCtx.ChunkSize is below the input length. Reset the count to unknown whenever a validity bitmap is present, as the C++ ArraySpan::SetSlice does, and add the chunk-size test.
zeroshade
requested changes
Sep 15, 2026
zeroshade
left a comment
zeroshade
left a comment
Member
There was a problem hiding this comment.
The null-count invalidation fix and focused chunk-size tests pass. One required release-audit fix remains: the new test file needs the standard ASF header.
| @@ -0,0 +1,60 @@ | |||
| package compute_test | |||
Member
There was a problem hiding this comment.
Please add the standard ASF license header to this new source file. Apache RAT 0.16.1, using this PR's check_rat_report.py and exclusion list, reports NOT APPROVED: arrow/compute/scalar_boolean_chunksize_test.go. The ordinary test file should be licensed rather than excluded from RAT.
Contributor
Author
|
Added the standard ASF header to arrow/compute/scalar_boolean_chunksize_test.go in the |
singhpratech
added a commit
to singhpratech/ArrowMetal
that referenced
this pull request
Sep 15, 2026
…eader added, awaiting re-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale for this change
and_kleeneandor_kleenereturnfalsewhere the answer is null whenExecCtx.ChunkSizeisbelow the input length (#1305).
ArraySpan.SetSlicekept the cached null count for the newslice when it was
0or equal to the old length. That is only right while the count describes thewhole span. The executor reuses one span per argument across slices, and a kernel that calls
UpdateNullCount()on it stores the slice's count, so the nextSetSlicetreats the followingslice as all valid or all null.
What changes are included in this PR?
SetSliceresets the count toUnknownNullCountwhenever a validity bitmap is present, as the C++ArraySpan::SetSlicedoes (cpp/src/arrow/array/data.h), and keeps it unknown when it was alreadynon-zero without a bitmap. The null type still gets the slice length; a span with no bitmap and a
zero count keeps zero. Two cases added to
TestArraySpan_SetSlice, and a new test that runs bothKleene kernels at chunk sizes 1, 2, 3, 4 and 8 against the default result.
Cost: a slice of an all-valid array with a bitmap now reports an unknown count, so a kernel that
asks pays one popcount over the slice instead of reading the cache. That is the C++ behaviour.
Are these changes tested?
Yes. The new chunk-size test fails on main (four assertions, chunk sizes 1 and 2 for both kernels)
and passes with the change;
go test ./arrow/compute/...passes.Are there any user-facing changes?
Results of
and_kleene/or_kleeneno longer depend onExecCtx.ChunkSize.ArraySpan.NullsafterSetSliceisUnknownNullCountin cases where it was previously0or the slice length; code thatread it directly should call
UpdateNullCount(), which is what the package's own kernels do.Closes #1305.