fix: grouped first_value/last_value FILTER excludes NULL predicate rows#23707
Open
u70b3 wants to merge 2 commits into
Open
fix: grouped first_value/last_value FILTER excludes NULL predicate rows#23707u70b3 wants to merge 2 commits into
u70b3 wants to merge 2 commits into
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #23707 +/- ##
=======================================
Coverage 80.71% 80.71%
=======================================
Files 1089 1089
Lines 368275 368338 +63
Branches 368275 368338 +63
=======================================
+ Hits 297250 297310 +60
+ Misses 53309 53305 -4
- Partials 17716 17723 +7 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
SQL aggregate FILTER semantics pass a row only when the predicate is `true`; rows where the predicate evaluates to `null` must be excluded. FirstLastGroupsAccumulator::get_filtered_extreme_of_each_group checked only `BooleanArray::value(idx)`, so a NULL predicate row whose underlying value bit is set (as produced by comparison kernels) was treated as passing, producing a non-NULL aggregate where all rows should have been filtered out. The same validity-blind read existed for `is_set_arr`, which is not only an internal bitmap: `convert_to_state` stores the user FILTER clause (including its nulls) in the last state column, so on the merge path (e.g. skip-partial-aggregation) NULL predicate rows were likewise treated as set. Both reads now require `is_valid(idx) && value(idx)`, matching the convention used by variance/correlation. Closes apache#22666. Co-Authored-By: Claude <noreply@anthropic.com>
u70b3
force-pushed
the
fix/first-last-filter-null-predicate
branch
from
July 20, 2026 04:58
2a668d3 to
f4b1300
Compare
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
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
Under SQL aggregate
FILTERsemantics, a row passes only when the predicate evaluates totrue; rows where the predicate isnullmust be excluded. Groupedfirst_value/last_valuechecked onlyBooleanArray::value(idx), without checking validity, so a NULL predicate row whose underlying value bit is set (as produced by comparison kernels, e.g.null::int < 1) was treated as passing:What changes are included in this PR?
datafusion/functions-aggregate/src/first_last.rs, inFirstLastGroupsAccumulator::get_filtered_extreme_of_each_group(shared byfirst_valueandlast_value, and by both theupdate_batchandmerge_batchpaths):passed_filternow requiresis_valid(idx) && value(idx)(theSome(true)semantics), matching the convention already used byvariance.rs/correlation.rs.is_set_arrread gets the same validity check. This is not only an internal bitmap:convert_to_statestores the user FILTER clause (including its nulls) in the last state column, so on the merge path (e.g. skip-partial-aggregation) NULL predicate rows were likewise treated as set. Verified with a forced skip-partial run (100k unique groups, all-NULL predicates): 83,616 groups were incorrectly assigned non-NULL values before the fix, 0 after. For genuine internal bitmaps (no nulls) the added check is trivially true, so behavior there is unchanged.Regression coverage:
aggregate.slt): the issue reproducer, thelast_valuecounterpart, mixed TRUE/FALSE/NULL predicates, all-TRUE and no-FILTER controls, the (already correct) non-grouped path, and a window-function no-regression case.test_group_acc_filter_null_predicate(update path) andtest_group_acc_merge_null_is_set(merge path viaconvert_to_state→merge_batch), both constructingBooleanArrays whose null slots carry a set value bit.Are these changes tested?
Yes — see above. Verified
./dev/rust_lint.sh,cargo test -p datafusion-functions-aggregate --lib, theaggregate/windowsqllogictest files, anddatafusion-cliend-to-end (grouped first/last_value now return NULL for the issue reproducer; mixed-predicate and non-grouped results unchanged).Also audited the rest of
functions-aggregatefor the same validity-blind pattern: shared helpers (nulls.rs::filter_to_validity,accumulate.rs,prim_op.rs,count.rs,array_agg.rs,variance.rs,correlation.rs) already handle validity correctly, and non-grouped paths pre-filter with arrow'sfilterkernel (which drops NULL predicate rows), so no other aggregate needs changes.Performance
functions-aggregate/benches/first_last.rswas run againstmain. The added checks are one validity-bit test per row on the grouped path; measured deltas were within the machine's noise floor (±5% on unchangedfilter=falsecases). A variant hoisting the null check out of the row loop showed no measurable benefit beyond noise, so the simple idiomatic form is kept.Are there any user-facing changes?
Only the bug fix: grouped
first_value/last_valuewith a nullableFILTERpredicate now correctly exclude NULL-predicate rows, matching SQL semantics and the behavior of other aggregates. No API or configuration changes.