Repository navigation
perf: copy bitmaps a word at a time in pre_selection_scatter - #25494
Open
abokhalill wants to merge 1 commit into
Open
abokhalill wants to merge 1 commit into
abokhalill wants to merge 1 commit into
Conversation
Contributor
|
@abokhalill |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #25494 +/- ##
==========================================
- Coverage 82.73% 82.73% -0.01%
==========================================
Files 1147 1147
Lines 449459 449412 -47
Branches 449459 449412 -47
==========================================
- Hits 371864 371812 -52
- Misses 54936 54946 +10
+ Partials 22659 22654 -5 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Slicing the RHS array per selected run clones and drops an Arc on every iteration, and iterating the slice sets one bit per row while both sides are already bit-packed. Borrow the RHS buffers once and copy each run with append_packed_range. Only build a validity bitmap when the RHS has nulls, so a null-free result does not pay a second pass per run. TPC-H SF30 on 24 threads: q6 -8.3%, q12 -4.1%, q19 -2.0%, others within noise.
abokhalill
force-pushed
the
perf-pre-selection-scatter-bulk-copy
branch
from
October 7, 2026 17:57
b1a7913 to
7a60002
Compare
Author
|
@kosiew done. the speedups are actually even more prominent now! |
Contributor
|
run benchmark binary_op env:
BENCH_FILTER: short_circuit |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing perf-pre-selection-scatter-bulk-copy (7a60002) to f9b7f34 (merge-base) diff Run configurationrun benchmark binary_op
env:
BENCH_FILTER: "short_circuit"Results will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing perf-pre-selection-scatter-bulk-copy (7a60002) to f9b7f34 (merge-base) diff Run configurationrun benchmark binary_op
env:
BENCH_FILTER: "short_circuit"CPU Details (lscpu)Details
Resource Usagebinary_op — base (merge-base)
binary_op — branch
File an issue against this benchmark runner |
kosiew
approved these changes
Oct 9, 2026
kosiew
left a comment
kosiew
left a comment
Contributor
There was a problem hiding this comment.
Thanks for working on this optimization. The packed bitmap copying addresses the unnecessary RHS slicing and per-row Boolean processing while preserving the existing scatter behavior. I found no blocking issues, just two minor suggestions to avoid an unnecessary allocation and improve regression coverage.
| let right_bytes = right_values.values(); | ||
| let right_nulls = right_result.nulls(); | ||
|
|
||
| let mut values = BooleanBufferBuilder::new(result_len); |
Contributor
There was a problem hiding this comment.
Could we move result_array_builder initialization into the None branch? The new Some branch allocates its own bitmap builder and returns without using the original one, so this would avoid an unnecessary allocation and free.
| .iter() | ||
| .for_each(|v| result_array_builder.append_option(v)); | ||
| let from = right_offset + right_array_pos; | ||
| values.append_packed_range(from..from + len, right_bytes); |
Contributor
There was a problem hiding this comment.
Could we add a scatter regression test covering nullable RHS values, non-byte-aligned offsets, runs crossing byte and 64-bit boundaries, and leading, intermediate, and trailing gaps with both fill values? Please include independently offset value and validity buffers, since ordinary slices usually share the same offset, and compare the output against a simple row-wise reference.
Contributor
|
run benchmark binary_op env:
BENCH_FILTER: short_circuit |
Contributor
|
Trying to see if performance changes are reproducable |
|
🤖 Benchmark running (GKE) | trigger CPU Details (lscpu)Comparing perf-pre-selection-scatter-bulk-copy (7a60002) to f9b7f34 (merge-base) diff Run configurationrun benchmark binary_op
env:
BENCH_FILTER: "short_circuit"Results will be posted here when complete File an issue against this benchmark runner |
|
🤖 Benchmark completed (GKE) | trigger Instance: Comparing perf-pre-selection-scatter-bulk-copy (7a60002) to f9b7f34 (merge-base) diff Run configurationrun benchmark binary_op
env:
BENCH_FILTER: "short_circuit"CPU Details (lscpu)Details
Resource Usagebinary_op — base (merge-base)
binary_op — branch
File an issue against this benchmark runner |
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
5 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.
Which issue does this PR close?
Rationale for this change
pre_selection_scatterputs the short-circuited RHS result back at full batch length. For each run of selected rows it slices the RHS and appends oneOption<bool>at a time, even though both sides are bit-packed, and everysliceclones and drops anArc.Since #25771,
ANDchains of cheap comparisons no longer reach this function, so TPC-H is unchanged. It still runs forOR, and forANDwith a conjunct that is not cheap.TPC-H SF30
lineitem, 24 threads,l_quantity > K or l_discount > 0.05, by share of rows that reach the RHS:l_quantity < K and l_comment like '%special%'is 1-2% faster. The 22 TPC-H queries are within noise.What changes are included in this PR?
Borrow the RHS buffers once, copy each run with
append_packed_range, and only build a validity bitmap when the RHS has nulls.Are these changes tested?
Yes, by the existing tests, including
test_pre_selection_scatter.Are there any user-facing changes?
No.