JingsongLi commented on code in PR #1145:
URL: https://github.com/apache/paimon-rust/pull/1145#discussion_r4371231645
##########
crates/paimon/src/table/global_index_scanner/evaluator.rs:
##########
@@ -670,9 +680,11 @@ impl GlobalIndexScanner {
// Only a proven identity remains (other conjuncts may have
// declined their budget). Preserve its indexed domain and
// leave the residual filter to the ordinary table reader.
+ bitmap_retained |= matches!(entry.index_type,
GlobalIndexFileKind::Bitmap);
all_matching_ranges.push(RowRange::new(entry.row_range_start,
entry.row_range_end));
continue;
}
+ bitmap_retained |= matches!(entry.index_type,
GlobalIndexFileKind::Bitmap);
Review Comment:
[P2] Determine Bitmap contribution after querying the posting
A Bitmap shard can survive metadata pruning yet contribute no rows. Setting
this flag before querying still downgrades an exact BTree answer in that case.
I reproduced with an old finite Bitmap on f=[0,2], then appended f=[1,3] and
built BTree(f) plus IVF: for `f > 0.5 AND f = 1`, the Bitmap min/max cannot
prune f=1, but its actual equality posting is empty, so only the exact BTree
hit (row ID 2) remains. With `global-index.filter.refine-from-data=false`, this
head returns [] instead of [2]; exact base 4cf34379 returns [2]. On this head,
equality alone without refinement and the conjunction with refinement both
return [2]. This is not a contributing inexact Bitmap candidate: its query
result is empty. Track whether Bitmap actually adds nonempty ranges when
combining query results, rather than marking its planned query as a
contribution.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
