Why isn't Postgres using my index? | Postgres.FM 085 | #PostgreSQL #Postgres podcast

[ 🇬🇧_🇺🇸 Check out the subtitles – we now edit them, ChatGPT+manually! You can also try YouTube's auto-translation of them from English to your language; try it and share it with people interested in Postgres!]

Nikolay and Michael discuss a common question — why Postgres isn't using an index when you think it should be!

Here are some links to things they mentioned:

~~~

~~~

Postgres FM is brought to you by:

~~~

[kirkwolak]

We noticed some of our most important queries in PG16 had improved performance!

[ilyaportnov]

a couple of reasons I think deserve mentioning in this context:
* there are different operator families, and they support different operators. For example, default btree index on text field does not support `like` operator; you have to do either `collate "C"`, or text_pattern_ops; on the other hand, text_pattern_ops does not support inequaltiy comparation (</>) and sorting.
* there are different collations; if your index is, for example, `collate "C"`, but you do comparasion by equality with default collation, the index will not work - you have to specify collation in the query explicitly or rebuild the index with another collation.
* and, talking about selectivity / cardinality, there is a more difficult type of problems, when PG can not correctly calculate cardinality because of several joins: it can calculate cardinality of join result when you join two tables, but then when you join the result of join with the third table, it will probably not be able to calculate cardinality correctly. In this case I don't know a simple way to fix such problem, apart of rewriting one query into several or using materailized views or smth like that. Because of cardinality miscalculation, PG can select totally wrong sequence of joins, and because of that it will not use index... You can try to force the order of joins by use CTEs with `materialized` keyword to make an optimization barrier. Or even switch to Max Boguk's hardcore techniques with recursive CTEs :)

[marcinbadtke]

Thank you for the conversation.

It is hard to imaging for me that disk performance is the main reason database engine chooses to use index or not. As far as I know during sequential scan many database blocks are read in one IO operation. On the other hand random read reads only one database block.

In my opinion using index or not is decided based primarily on statistics. Index is not used when cost calculation based on statistics shows that not using index is optimal. E.g. statistics show that amount of data a query tries to get is so big that it is cheaper to do sequential scan.

[mbanck]

Current versions of hypopg an also mask an index, for the "would it pick my index if the other one does not exist?" question

[wstrzalka]

It's still 4 on RDS. And when raised to their support the answers was it's not related to hardware and I should set it myself to whatever I want :)

[agarbanzo]

Why doesn’t Postgres do some detection of the disk type and do basic, deterministic self tuning?