Ryan has a valid point here. Once the Bloom filters get released, it won't be as easy anymore to change it because we will break an already released API.
There was a related discussion a while ago: https://lists.apache.org/thread.html/027e9d73093df84448e07d8514b9d669906cd5b83ae59a76f38aaa55@%3Cdev.parquet.apache.org%3E My suggestion would be to create a VOTE to formally adopt the vote and fix the remaining concerns. For example, the one that Zoltan raised in the list above. Cheers, Fokko Op vr 28 jun. 2019 om 01:13 schreef Jim Apple <[email protected]>: > > I think we need to have a vote on the bloom filter > > structures first. We need to make sure that the community has vetted the > > design and is comfortable with adding this, just like we did with the > > Parquet encryption design and the page index design. > > Thank you for the note, Ryan. Based on my experience on Apache Impala, I > was under the impression that a git commit signified at least a temporary > agreement that the commit should make it into a future release. I > understand you to be saying that in parquet-format, a vote on format > additions is standard, whether or not a commit made it into HEAD. > > There have been previous discussions of Bloom filters in the pull > requests, on this list, and in live videochat meetups (from quite a while > ago). In your opinion, should we start a new discussion, or start a [VOTE] > thread with pointers to the old discussions, or some third option? >
