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 23:11:40
Message-ID: 786214a0-8f24-5905-7473-a65d948aab38@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Here is a slightly improved version of the patch series.

Firstly, I realized the PG_DETOAST_DATUM() in brin_bloom_summary_out is
actually needed - the value can't be toasted, but it might be stored
with just 1B header. So we need to expand it to 4B, because the struct
has int32 as the first field.

I've also removed the sort mode from bloom filters. I've thought about
this for a long time, and ultimately concluded that it's not worth the
extra complexity. It might work for ranges with very few distinct
values, but that also means the bloom filter will be mostly 0 and thus
easy to compress (and with very low false-positive rate). There probably
are cases where it might be a bit better/smaller, but I had a hard time
constructing such cases. So I ditched it for now. I've kept the "flags"
which is unused and reserved for future, to allow such improvements.

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-20210114.patch text/x-patch 23.5 KB
0002-Move-IS-NOT-NULL-handling-from-BRIN-support-20210114.patch text/x-patch 23.3 KB
0003-Optimize-allocations-in-bringetbitmap-20210114.patch text/x-patch 4.4 KB
0004-BRIN-bloom-indexes-20210114.patch text/x-patch 129.6 KB
0005-BRIN-minmax-multi-indexes-20210114.patch text/x-patch 217.3 KB
0006-Ignore-correlation-for-new-BRIN-opclasses-20210114.patch text/x-patch 4.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-01-13 23:22:02 Re: pg_preadv() and pg_pwritev()
Previous Message James Coleman 2021-01-13 22:52:16 Re: [DOC] Document concurrent index builds waiting on each other