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 |
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 |