Re: WIP: BRIN multi-range indexes

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: WIP: BRIN multi-range indexes
Date: 2021-01-13 01:09:19
Message-ID: 79869c9d-95a2-0940-76a8-29c348707a66@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 1/12/21 6:28 PM, John Naylor wrote:
> On Sat, Dec 19, 2020 at 8:15 PM Tomas Vondra
> <tomas(dot)vondra(at)enterprisedb(dot)com <mailto:tomas(dot)vondra(at)enterprisedb(dot)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

Attachment Content-Type Size
0001-Pass-all-scan-keys-to-BRIN-consistent-funct-20210112.patch text/x-patch 23.5 KB
0002-Move-IS-NOT-NULL-handling-from-BRIN-support-20210112.patch text/x-patch 23.3 KB
0003-Optimize-allocations-in-bringetbitmap-20210112.patch text/x-patch 4.4 KB
0004-BRIN-bloom-indexes-20210112.patch text/x-patch 139.0 KB
0005-bloom-fixes-and-tweaks-20210112.patch text/x-patch 11.7 KB
0006-add-sort_mode-opclass-parameter-20210112.patch text/x-patch 3.7 KB
0007-BRIN-minmax-multi-indexes-20210112.patch text/x-patch 217.3 KB
0008-Ignore-correlation-for-new-BRIN-opclasses-20210112.patch text/x-patch 4.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuro Yamada 2021-01-13 01:22:05 Re: list of extended statistics on psql
Previous Message Thomas Munro 2021-01-12 23:40:59 Re: pg_preadv() and pg_pwritev()