Efficiency of indexes for a field with low cardinality - database

Question

For example There is a field ( can be null) in a postgres database which stores enum value and that enum has only two values A,B.
Now my all select query have where clause on this field.
I have a question will adding a index to this field will be a good approach or it will not increase any performance as each row contains either A or B or a null.
Is there a way i can increase performance of all get call.
Please help

Answer 1

No. In most cases, an index on a low-cardinality column (or: a set of columns with a low cardinality) is useless. Instead, you could use a conditional index. As an example, my tweets - table, with a handful boolean columns:
twitters=# \d tweets
Table "public.tweets"
Column | Type | Collation | Nullable | Default
----------------+--------------------------+-----------+----------+---------
seq | bigint | | not null |
id | bigint | | not null |
user_id | bigint | | not null |
in_reply_to_id | bigint | | not null | 0
parent_seq | bigint | | not null | 0
sucker_id | integer | | not null | 0
created_at | timestamp with time zone | | |
fetch_stamp | timestamp with time zone | | not null | now()
is_dm | boolean | | not null | false
is_reply_to_me | boolean | | not null | false
is_retweet | boolean | | not null | false
did_resolve | boolean | | not null | false
is_stuck | boolean | | not null | false
need_refetch | boolean | | not null | false
is_troll | boolean | | not null | false
body | text | | |
zoek | tsvector | | |
Indexes:
"tweets_pkey" PRIMARY KEY, btree (seq)
"tweets_id_key" UNIQUE CONSTRAINT, btree (id)
"tweets_stamp_idx" UNIQUE, btree (fetch_stamp, seq)
"tweets_du_idx" btree (created_at, user_id)
"tweets_id_idx" btree (id) WHERE need_refetch = true
"tweets_in_reply_to_id_created_at_idx" btree (in_reply_to_id, created_at) WHERE is_retweet = false AND did_resolve = false AND in_reply_to_id > 0
"tweets_in_reply_to_id_fp" btree (in_reply_to_id)
"tweets_parent_seq_fk" btree (parent_seq)
"tweets_ud_idx" btree (user_id, created_at)
"tweets_userid_id" btree (user_id, id)
"tweets_zoek" gin (zoek)
Foreign-key constraints:
...
The "tweets_in_reply_to_id_created_at_idx" index only has entries for rows that fulfill the condition. Once the reference is refetched (or failed to do so) they are removed from the index. So, this index will usually only have a few pending records.
A different example: a gender column. You'd expect a 50/50 distribution of male/female. Assuming a rowsize of ~100, there are ~70 rows on an 8K page. Probably there will be both males and females on the same page, so even a search for males-only or females-only would need to read all the pages. (needing to read the index will worsen this, but the optimiser will wisely decide to ignore the index) A clustered index may help, but will need a lot of maintenance work. Not worth the wile.

Answer 2

An index just on that column is unlikely to be useful, unless the distribution of values is very skewed (e.g. 99% A, 0.99% NULL, 0.01% B). But in that case you would probably be better off with a partial index on some other field WHERE this_field='B'.
But even with an more uniform distribution of values (33.33% A, 33.33% NULL, 33.33% B) it could be useful to include that column as the leading column in some multicolumn indexes. For example, for WHERE this_field='A' and other_field=7945, the index on (this_field, other_field) would generally be about 3 times more efficient than one on just (other_field) if the distribution of value is even.
Where it could make a huge difference is with something like WHERE this_field='A' ORDER by other_field LIMIT 5. With the index on (this_field, other_field) it can jump right to the proper spot in the index and read off the first 5 rows (which pass checking for visibility) already in order and then stop. If the index were just on (other_field) it might, if the two columns are not statistically independent of each other, have to skip over any arbitrary number of 'B' or NULL rows before finding 5 with 'A'.

Answer 3

In the case when NULL is not so often in the column you can partitioning the table and process only required part automatically when this field used in condition without any additional indexes.