Tracking issue of bloom filter refactoring

[drmingdrmer]

Problems

• Bloom filter index takes too much storage space, e.g., about 50% of the original data size.
• With a bloom filter index, an exact-match query from 10 billion rows still takes minutes.

The goals are:

• to try to accelerate queries, at least for explicitly simple queries.
• to reduce index size if possible.

Issues:

• read_bloom_filter_index() take 2min for ontime #7379
• bug: point query(BloomFilter) EXPLAIN read a lot of data #7674

Let me know if there are any other issues related bloom filter.:)

Status

• 2022-09-20: It's still under investigation and I can not tell for now what will be done:(

[drmingdrmer]

@BohuTANG @dantengsky @sundy-li @youngsofun

[BohuTANG]

@drmingdrmer

We will first try the XOR filter instead of the old raw bloom filter, then @dantengsky will help me to adapt the raw bloom filter to the new XOR filter.
The new XOR filter is here:
#7860

From my test, it looks great, let's try :)

[BohuTANG]

@drmingdrmer

I have moved the issues related to the index(not only the bloom filter) to #7823. Let's close this :)