Hacker News Reader

Is the query actually slower, or is it just not using an index you want it to use?

Often times PG won’t bother with an index for a variety of reasons (sequential scans can be legitimately faster in some scenarios), especially when the number of rows is small.

View on HN

The cool thing about hints is you can quickly drop in a hint to confirm your suspicions and narrow down the problem, rather than trying to do this sort of diagnosis in a vacuum. But because some people use hints for evil, nobody is allowed to use them.

You can also disable seq_scan and force pg to consider indexes, usually that's enough.

Access method is just part of the story. Same index may be accessed in different ways, you might also want to combine them. Sometimes you may change table join order to see how it estimates (or executes). Usually there are two parts 1) cost and reasoning for some estimation 2) how it executes (timings, resource usage, locks/contention)

The query is slower otherwise I would not even notice, I don't care which index it uses if its fast.

It's not just about index usage, its also which type of join (loop, hash or merge) and join order.

Reply on news.ycombinator.com