I've noticed one interesting side-effect with B-tree index compression in #PostgreSQL 13+: The planner now sometimes picks a less-desirable index. 1/n
Conversation
If you have a very low-cardinality field (say, a status field with only seven values), index compression *really* shrinks the size of an index on that field… to the point that the planner *loves* to use it… 2/n
2
2
Replying to
The lower the cardinality, the smaller index - up to a point. That point is 10 - 15 rows per distinct value. It "saturates" at ~3.5x size reduction (barring very large keys, say on text). Cardinality doesn't have to be "very low" to saturate. Can you report the issue to -bugs?