Skip to content

fix(compute/exec): do not carry a cached null count across ArraySpan.SetSlice - #1306

Open
singhpratech wants to merge 1 commit into
apache:mainfrom
singhpratech:fix-exec-setslice-null-count
Open

fix(compute/exec): do not carry a cached null count across ArraySpan.SetSlice#1306
singhpratech wants to merge 1 commit into
apache:mainfrom
singhpratech:fix-exec-setslice-null-count

Conversation

@singhpratech

Copy link
Copy Markdown
Contributor

Rationale for this change

and_kleene and or_kleene return false where the answer is null when ExecCtx.ChunkSize is
below the input length (#1305). ArraySpan.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. The executor reuses one span per argument across slices, and a kernel that calls
UpdateNullCount() on it stores the slice's count, so the next SetSlice treats the following
slice as all valid or all null.

What changes are included in this PR?

SetSlice resets the count to UnknownNullCount whenever a validity bitmap is present, as the C++
ArraySpan::SetSlice does (cpp/src/arrow/array/data.h), and keeps it unknown when it was already
non-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 both
Kleene 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_kleene no longer depend on ExecCtx.ChunkSize. ArraySpan.Nulls after
SetSlice is UnknownNullCount in cases where it was previously 0 or the slice length; code that
read it directly should call UpdateNullCount(), which is what the package's own kernels do.

Closes #1305.

…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

1 participant