You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] range-bitmap file index: IS NULL returns only the first and last row when a column is entirely NULL in a file #10332
The same table with file-index.bitmap.columns or file-index.bsi.columns instead of range-bitmap returns 5.
What doesn't meet your expectations?
c IS NULL returns 2 rows; all 5 rows match. The rows returned are the first and the last row of the file; every row in between is dropped.
The same table with file-index.bitmap.columns or file-index.bsi.columns instead of range-bitmap returns 5.
Anything else?
Root cause is in org.apache.paimon.fileindex.rangebitmap.RangeBitmap#isNull. When the column has no non-null value in the file (cardinality <= 0), it returns:
RoaringBitmap32.bitmapOf(0, rid - 1)
bitmapOf(int...) takes a list of positions, so this is the two-element set {0, rid - 1}, not the range [0, rid). Any file with three or more rows where the indexed column is entirely NULL loses its middle rows for IS NULL.
Suggested fix: return the full range, e.g. RoaringBitmap32.bitmapOfRange(0, rid). isNotNull on the same reader is correct (it returns an empty bitmap for such a file), so the complement of isNotNull over [0, rid) gives the right answer too.
I checked this against the current master branch. The all-null case is already fixed there: RangeBitmap#isNull returns RoaringBitmap32.bitmapOfRange(0, rid) when cardinality <= 0, and RangeBitmapFileIndexTest#testOnlyNulls covers five null rows and expects the full [0, 5) range.
So there is no additional code change to contribute for this one without duplicating the existing fix. Could a maintainer confirm which release contains the fix and close this issue as already fixed?
Activity
spancer commentedon Oct 2, 2026
I checked this against the current
masterbranch. The all-null case is already fixed there:RangeBitmap#isNullreturnsRoaringBitmap32.bitmapOfRange(0, rid)whencardinality <= 0, andRangeBitmapFileIndexTest#testOnlyNullscovers five null rows and expects the full[0, 5)range.So there is no additional code change to contribute for this one without duplicating the existing fix. Could a maintainer confirm which release contains the fix and close this issue as already fixed?