From: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: WIP: BRIN multi-range indexes |
Date: | 2021-03-27 20:42:05 |
Message-ID: | f673a88a-5d68-da56-8da8-08c2a4eff610@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 3/27/21 7:09 PM, Alvaro Herrera wrote:
> On 2021-Mar-26, Tomas Vondra wrote:
>
>> Hi,
>>
>> I've pushed both the bloom and minmax-multi indexes today.
>
> One thing I've been wondering all along is how useful are these
> BRIN-backed bloom indexes compared to contrib-supplied bloom indexes.
> My guess is that the BRIN implementation has some advantage, or you
> would not have worked so much on it. But what is it?
>
The contrib/bloom indexes are a completely different type of index. They
are not BRIN but a completely separate AM. The bloom filters are per-row
(so the index is larger than BRIN) and it's useful when you have table
with many attributes, and need to test various combinations of them.
create table t (a int, b int, c int);
insert into t select 10 * random(), 10 * random(), 10 * random()
from generate_series(1,1000000) s(i);
analyze t;
create index bloom_idx on t using bloom (a,b,c)
with (length=80, col1=4, col2=4, col3=4);
create index brin_bloom_idx on t using
brin (a int4_bloom_ops, b int4_bloom_ops, c int4_bloom_ops);
test=# \di+
List of relations
Schema | Name | Table | Access Method | Size | Description
--------+----------------+-------+---------------+-------+-------------
public | bloom_idx | t | bloom | 15 MB |
public | brin_bloom_idx | t | brin | 88 kB |
(2 rows)
So it's a completely different kind of animal, perhaps closer to btree
than to BRIN. I'm sure there are cases where contrib/bloom works better
than brin/bloom, but also the other way around.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Joel Jacobson | 2021-03-27 20:47:40 | Re: [PATCH] pg_permissions |
Previous Message | Mark Rofail | 2021-03-27 20:41:34 | Re: [HACKERS] GSoC 2017: Foreign Key Arrays |