Re: Questions about btree_gin vs btree_gist for low cardinalitycolumns - Mailing list pgsql-general

From Thomas Kellerer
Subject Re: Questions about btree_gin vs btree_gist for low cardinalitycolumns
Date
Msg-id f2af83b5-ec6a-ce7f-7039-e8e91c2ae4c6@gmx.net
Whole thread Raw
In response to Re: Questions about btree_gin vs btree_gist for low cardinality columns  (Will Hartung <willhartung@gmail.com>)
List pgsql-general
Will Hartung schrieb am 31.05.2019 um 00:11:
> If you have 10M rows with a “STATUS” column of 1 or 2, and an index
> on that column, then you have a 2 node index with a bazillion row
> pointers. Some systems (I can’t speak to PG in this regard)
> degenerate in this kind of use case since the index is more or less
> designed to work great in unique identifiers than low cardinality
> values. The representation of large record pointer lists may just not
> be handled well as edge cases.

What I very often do in theses cases is to create two partial indexes: 

One with "WHERE status = 1" and another with "WHERE STATUS = 2" including 
_another_ column in the index that I usually use together with the status 
column in the queries.





pgsql-general by date:

Previous
From: "Peter J. Holzer"
Date:
Subject: Re: Questions about btree_gin vs btree_gist for low cardinalitycolumns
Next
From: Sonam Sharma
Date:
Subject: table is hanging