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