Thanks, The naming issue had been fixed, I also created a PR <https://github.com/apache/parquet-format/pull/139>to add xxHash as an alternative option for Todd's concern. Is that OK for concerns? If that is OK, we can create a VOTE against the spec (the bloom filter diff in parquet-format repo).
On Fri, Jun 28, 2019 at 4:03 PM Driesprong, Fokko <[email protected]> wrote: > 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? > > > -- Thanks & Best Regards
