RE: Questions about btree_gin vs btree_gist for low cardinality columns

From: Steven Winfield <Steven(dot)Winfield(at)cantabcapital(dot)com>
To: Morris de Oryx <morrisdeoryx(at)gmail(dot)com>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: RE: Questions about btree_gin vs btree_gist for low cardinality columns
Date: 2019-06-03 10:33:17
Message-ID: E9FA92C2921F31408041863B74EE4C2001BD706B65@ccpmaildag02.cantab.local
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> In the case of a single column with a small set of distinct values over a large set of rows, how would a Bloom filter be preferable to, say, a GIN index on an integer value? 

I don't think it would - it's probably better suited to the multi-column case you described previously.

> I have to say, this is actually a good reminder in my case. We've got a lot of small-distinct-values-big-rows columns. For example, "server_id", "company_id", "facility_id", and so on. Only a handful of parent keys with many millions of related rows. Perhaps it would be conceivable to use a Bloom index to do quick lookups on combinations of such values within the same table. I haven't tried Bloom indexes in Postgres, this might be worth some experimenting.

Yes, this is more like the use case I was thinking of.

Steve.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Lavoie 2019-06-03 14:10:33 Re: Postgresql backup via LVM snapshot?
Previous Message Morris de Oryx 2019-06-03 10:11:48 Re: Questions about btree_gin vs btree_gist for low cardinality columns