> It seems odd to me to not do any basic adjustment of random_page_cost though. It isn't a magic number that the core team know to be perfect. It is a baseline that is likely to be quite different for each use case and server config. While there are no hard and fast rules and absolute right answers, it seems prudent to at least follow the advice of the community and lower it a ways if storage is ssd style and/or cache hits are quite high. Ic. Well I don’t mine experimenting with it, and will certainly remember it next time. I guess I was demotivated because I read lot’s of warnings but these might have been about disabling sequential scans and not about page cost settings.
Ah yes. Don't handicap the system by removing a join or scan type. However, simply customizing costs that are used to decide between path A and path B when planning how to execute queries, that can definitely can be helpful to get better plans overall. Good luck!
