PARQUET-2251 Avoid generating Bloomfilter when all pages of a column are encoded by dictionary in parquet v1 - #1033
Merged
Conversation
…are encoded by dictionary in parquet pageV1
Contributor
Author
|
@wgtmac @gszadovszky Please take a look, thank you~ |
wgtmac
approved these changes
Feb 24, 2023
| @Parameterized.Parameters(name = "Run {index}: parquet {1}") | ||
| public static Collection<Object[]> params() { | ||
| return Arrays.asList( | ||
| new Object[]{FILE_V1, "pageV1"}, |
Member
There was a problem hiding this comment.
nit: the name is a little bit confusing. file format version is not same as data page version.
Contributor
Author
There was a problem hiding this comment.
thanks, I modified the description
Contributor
Author
|
@wgtmac @gszadovszky Thank you for your review and help |
This was referenced Sep 2, 2026
alamb
added a commit
to apache/arrow-rs
that referenced
this pull request
Sep 9, 2026
…hose data pages are all dictionary encoded (#10963) # Which issue does this PR close? - Closes #10962. # Rationale for this change A column chunk whose data pages are all dictionary encoded carries its exact set of distinct values in the dictionary page, so a bloom filter for it adds nothing a reader cannot already get exactly, while every value is still hashed into the filter during the write and the filter is serialized after the chunk. parquet-java stopped writing these in PARQUET-2251 (apache/parquet-java#1033, 1.13.0), so files from Spark, Hive and Iceberg never have a bloom filter on a dictionary-only chunk, and there was no way to get the same output from this crate. Details in #10962. # What changes are included in this PR? - `WriterProperties::bloom_filter_for_dictionary_encoded_chunks` with `WriterPropertiesBuilder::set_bloom_filter_for_dictionary_encoded_chunks` and `DEFAULT_BLOOM_FILTER_FOR_DICTIONARY_ENCODED_CHUNKS = true`, so the default output is unchanged. - In `GenericColumnWriter::close`, when the option is `false`, the bloom filter is dropped unless `encoding_stats` records at least one `DATA_PAGE`/`DATA_PAGE_V2` whose encoding is not `PLAIN_DICTIONARY` or `RLE_DICTIONARY`, the same test `ParquetFileWriter.writeColumnChunk` applies in parquet-java. `flush_bloom_filter` is still called so the encoder state is reset as before. # Are these changes tested? Yes, `test_bloom_filter_for_dictionary_encoded_chunks` writes a small dictionary-friendly Int32 column across the dictionary on/off × option on/off matrix and asserts a filter is present in every case except dictionary on with the option off. # Are there any user-facing changes? One new writer property, opt-in, documented on the setter. No breaking changes. --------- Co-authored-by: Andrew Lamb <andrew@nerdnetworks.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In parquet pageV1(Spark use parquet v1 default), even all pages of a column are encoded by dictionary, it will still generate BloomFilter. Actually it is unnecessary and it costs time and occupies storage. Parquet pageV2 doesn't have this problem.