On 1/12/21 6:28 PM, John Naylor wrote:
> On Sat, Dec 19, 2020 at 8:15 PM Tomas Vondra
> <tomas.vondra@enterprisedb.com <mailto:tomas.vondra@enterprisedb.com>>
> wrote:
> > [12-20 version]
>
> Hi Tomas,
>
> The measurements look good. In case it fell through the cracks, my
> earlier review comments for Bloom BRIN indexes regarding minor details
> don't seem to have been addressed in this version. I'll point to earlier
> discussion for convenience:
>
> https://www.postgresql.org/message-id/CACPNZCt%3Dx-fOL0CUJbjR3BFXKgcd9HMPaRUVY9cwRe58hmd8Xg%40mail.gmail.com
> <https://www.postgresql.org/message-id/CACPNZCt%3Dx-fOL0CUJbjR3BFXKgcd9HMPaRUVY9cwRe58hmd8Xg%40mail.gmail.com>
>
> https://www.postgresql.org/message-id/CACPNZCuqpkCGt8%3DcywAk1kPu0OoV_TjPXeV-J639ABQWyViyug%40mail.gmail.com
> <https://www.postgresql.org/message-id/CACPNZCuqpkCGt8%3DcywAk1kPu0OoV_TjPXeV-J639ABQWyViyug%40mail.gmail.com>
>
Attached is a patch, addressing those issues - particularly those from
the first link, the second one is mostly a discussion about how to do
the hashing properly etc. It also switches to the two-hash variant, as
discussed earlier.
I've changed the range to allow false positives between 0.0001 and 0.25,
instead the original range (0.001 and 0.1). The default (0.01) remains
the same. I was worried that the original range was too narrow, and
would prevent even sensible combinations of parameter values. But now
that we reject bloom filters that are obviously too large, it's less of
an issue I think.
I'm not entirely convinced the sort_mode option should be committed. It
was meant only to allow benchmarking the hash approaches. In fact, I'm
thinking about removing the sorted mode entirely - if the bloom filter
contains only a few distinct values:
a) it's going to be almost entirely 0 bits, so easy to compress
b) it does not eliminate collisions entirely (we store hashes, not the
original values)
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
