Repository navigation
test(parquet): add I/O tracking test for Bloom filter loading baseline - #26897
Conversation
aacf4dd to
587ce90
Compare
alamb
left a comment
alamb
left a comment
There was a problem hiding this comment.
Thanks for this @mohitgurav20
Can you please:
- Move this to a "end to end" test that uses datafusion public APIs (dataframe or SQL, preferably SQL)
- Move to using insta snapshots
The test hould do something like:
- Create a test parquet file
- REad the test parquet file using an instrumented object store
- Report the series of events
Something like
Read data page for column 1 (offsets...)
Read PageInded for column 1 (ofsets...)
Produce batch (1024 rows)
Read Bloom Filter for column 1 (offsets...)
Then the log should be rendered as text and compared to a snapshot using insta snapshot
…ng baseline - Add InstrumentedObjectStore that correlates requested byte ranges to Parquet file structures (footers, page indexes, bloom filters, data pages) - Add test_parquet_bloom_filter_io_baseline using public SessionContext SQL APIs - Use insta snapshot to capture and compare the storage I/O trace - Documents baseline on main where all candidate column Bloom filters are loaded upfront, establishing the target diff for incremental pruning (apache#25811)
5788ada to
c0a70fb
Compare
github-actions
Bot
added
core
|
hiii @alamb The snapshot records that both bloom filters are loaded upfront on main. Once this lands, #25811's diff on the snapshot will cleanly show the second fetch skipped. |
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Split the Bloom filter I/O test into reusable setup code in tests/parquet/io/mod.rs and the test itself in tests/parquet/io/bloom_filter_io.rs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
alamb
left a comment
alamb
left a comment
There was a problem hiding this comment.
Thank you very much @mohitgurav20 -- this is great.
I took the liberty to rework the tests a little so they are structured to accept other behaviors as well (specifically with predicate pushdown)
let me know what you think
cc @haohuaijin
| use std::sync::Arc; | ||
| use tempfile::NamedTempFile; | ||
|
|
||
| mod bloom_filter_io; |
| // Loads the Bloom filters, finds a match, then reads the data pages and | ||
| // produces a batch. | ||
| assert_snapshot!(test.query("SELECT * FROM t WHERE a = 10 AND b = 100").await, @r" | ||
| --- Query: SELECT * FROM t WHERE a = 10 AND b = 100 (1 rows) --- |
There was a problem hiding this comment.
I am biased, but quite pleased with this test - it shows clearly the IO pattern of the reader
|
Thanks @alamb, the refactor looks great! Splitting the test fixture into Happy with these changes as-is. Once this lands in |
haohuaijin
left a comment
haohuaijin
left a comment
There was a problem hiding this comment.
LGTM, Thanks @alamb @mohitgurav20
|
thanks for you review,time and guidance @alamb @haohuaijin |
|
Thanks everyone |
Which issue does this PR close?
Part of #25797. Baseline for #25811.
Rationale for this change
In #25811 we evaluate Parquet bloom filters incrementally during row group pruning to avoid fetching filters for later columns when an earlier column already rejects the row group.
Per review discussion on #25811, this PR adds a baseline test to
mainusing a trackingAsyncFileReader(similar toarrow-rsasync reader tests). It records thatmaincurrently fetches all candidate column bloom filters upfront (2 requests for a 2-column query where the first column is absent).Once this merges, #25811 will rebase on top and show the skipped fetch directly in the test diff.
What changes are included in this PR?
RangeTracker,TrackingAsyncReader, andTrackingReaderFactoryindatafusion/datasource-parquet/src/opener/mod.rsto record requested byte ranges.test_bloom_filter_io_pattern_baselineasserting current upfront fetch behavior onmain.Are these changes tested?
Yes, via
test_bloom_filter_io_pattern_baseline.Are there any user-facing changes?
No.