Fix nullable IN-list runtime semantics#25467
Conversation
Qodo reviews are paused for this user.Troubleshooting steps vary by plan Learn more → On a Teams plan? Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center? |
XuPeng-SH
left a comment
There was a problem hiding this comment.
Reviewed the nullable IN-list runtime and pruning fix.
The direction looks correct. The runtime IN/NOT IN operators now preserve SQL three-valued logic when the RHS contains NULL: matches still return true/false as expected, while no-match rows become UNKNOWN. The folded-vector change also addresses the real root cause: nullable list vectors are no longer sorted/compacted in a way that can desynchronize payload order from the null bitmap.
I also checked the pruning paths. For nullable folded vectors, readutil disables sorted min/max seek shortcuts, and ZM.AnyIn falls back to scanning non-null values. SubVecIn returning the full range for nullable vectors is conservative for bloom filtering; it can add false positives but should not incorrectly prune matching rows.
Local validation:
- go test ./pkg/sql/plan/function -count=1
- go test ./pkg/sql/colexec -count=1
- go test ./pkg/vm/engine/readutil -count=1
- go test ./pkg/vm/engine/tae/index -count=1
- go test ./pkg/sql/plan/rule -count=1
- go test ./pkg/sql/plan -run 'Test.*Fold|Test.*In|Test.*Filter' -count=1
CI is green. I did not find a blocking issue.
Merge Queue Status
This pull request spent 1 hour 35 minutes 22 seconds in the queue, including 1 hour 35 minutes 7 seconds running CI. Required conditions to merge
|
What type of PR is this?
Which issue(s) this PR fixes:
issue #25346
Follow-up to #25427.
What this PR does / why we need it:
The previous zonemap fix made block pruning conservative for nullable IN lists, but the SQL path can still fail before row-level filtering. Planner constant folding converts
INlist literals into a folded vector.Vector.InplaceSortAndCompact()sorts the vector payload without moving the null bitmap, so('keep', NULL)can become a vector where the null bitmap no longer points at the same value. The runtimeinoperator then skips the wrong RHS slot while building its hash map, andWHERE k IN ('keep', NULL)can filter out matchingkeeprows.This PR fixes the full path:
IN/NOT INreturn SQL UNKNOWN for no-match rows when the RHS contains NULL;AnyIn.Validated with the issue-shaped SQL on a dev node:
Local checks: