Repository navigation
fix(query): seed filter domains with boolean identities - #20803
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
⏱ CI timing · Devrun 39560811738 · 24.4 min (main p50 30.4 min, −6.0 min)
Minutes unless stated; durations exclude queue time unless stated; "max" = longest job in the group. Baseline = median of the last 10 successful runs (Dev: |
|
@codex review |
sundy-li
left a comment
There was a problem hiding this comment.
Automated AI-assisted review of ad36bb2514a649f075474905b1e9c28fe88ee811 on behalf of @sundy-li.
No blocking issue found after primary and independent review. The false/true seeds are the correct identities for or_filters/and_filters, whose Boolean output treats NULL as not-TRUE; ordinary nullable SQL AND/OR remain unchanged. Checked unknown domains, existing short-circuit/error handling, and the bloom/range consumers. The new result tests retain NULL OR TRUE and TRUE OR NULL rows as expected.
Validation: 354,288 local combinations of the extracted production initializer/merge closure matched an independent three-valued-logic oracle. Inspected exact-head CI run 39560811738: unit tests passed and the expanded explain/bloom_filter.test passed in HTTP and hybrid/TTC modes. These local checks are isolated domain probes, not a full local engine/workspace run.
This automated review does not replace the responsible human's full-diff review before merge.

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/
Motivation
Fix unnecessary block reads for OR predicates on nullable columns. A comparison may be known to return only FALSE or NULL; neither passes WHERE. If every OR branch has that property, the whole filter cannot match.
The old constant folder still marks TRUE as possible, so range/bloom pruning keeps blocks that contain no matches. Query results remain correct, but pruning is lost.
Reproduction
Use default settings in a fresh test schema. No SET or special table option is needed.
Each INSERT creates one block. Both searched strings are absent, but lie inside the min/max ranges, so bloom membership could exclude the blocks.
read rowspartitions totalpartitions scannedThe SELECT returns no rows in both versions. The difference is that the fix avoids planning reads of both blocks.
Approach
Start domain combination with FALSE for OR and TRUE for AND, rather than with both values possible. Argument handling and ordinary SQL NULL semantics are unchanged.
Tests
bloom_filter.testcovers impossible OR/IN predicates, nested AND, range pruning, matching branches that must retain a block, and actual returned rows where one OR branch is NULL and the other is TRUE. Comments explain the two-block layout and each expected pruning result. Rust test files are unchanged from main; the SQL coverage is not duplicated there.The expected result checks retain
NULL OR TRUEandTRUE OR NULLrows, while excluding a row where both branches are NULL. On the old implementation, the nullable-OR EXPLAIN reports the 6 rows / 2 scanned blocks above instead of zero.Type of change
AI assistance
This change is