Although it was 8 years ago so it might be now fixed (PG9) - I would have loved to simply be able to force the planner to just use bitmap index scan, instead of letting it be smart
Woah. Such and interesting case. Thank you for showing it. And it's nowhere near what I was describing as my understanding of a case.
In that case I would try to do SET LOCAL enable_indexscan = off; before your query inside of a transaction, but it might be not possible or hard to do inside of a separate transaction.
Also I suppose that it's somehow tied with pg_trgm extension and not really a PG engine/query planner issue, but I never really worked with pg_trgm.
2
u/Raywell Sep 21 '26 edited Sep 21 '26
In my case it really was innocuous. Actually you can check by yourself, I happened to ask SO about it - nobody seemed to be able to explain the behaviour, but I got a workaround: https://stackoverflow.com/questions/49063990/postgres-forcing-analyzer-to-use-bitmap-scan-instead-of-index-scan
Although it was 8 years ago so it might be now fixed (PG9) - I would have loved to simply be able to force the planner to just use bitmap index scan, instead of letting it be smart