PG does support hints actually.. and I used them to solve the last performance problem I had, rather than waiting n years for the query planner to be improved. The problem in question (from an automated query planning point of view) is the lack of multi-column statistics, leading to the wrong index being used. The only thing is, the hints are expressed in an obscure, ad-hoc and implementation dependant language. For example, the "Don't use index X" hint (the one I used) can be accessed by replacing your index with an index on values derived from the actual index, instead of the values themselves. Then that index is not available during normal query planning. Another example is the "Maybe use index on X and also sort by X" hint, which you access by adding "ORDER BY X" to your query. That would have solved my problem for a simple select, but it didn't help for an update. Then there's the "Don't use seq scan" hint, which is expressed as "set enable_seqscan=off". That can help when it mistakenly chooses seq scan. And there are many more such hints, which are regularly used by PG users to work around erroneous query plans. While writing this email, I had an idea for a FAQ, which would tell PG users how to access this informal hint language: Q: The query planner keeps choosing the wrong index. How do I force it to use the correct index? A: Have you analyzed your tables, increased statistics, etc etc etc? If that doesn't help, you can change the index to use a value derived from the actual row values. Then the index will not be available unless you explicitly use the derived values in your conditions. With such a FAQ, us people who use PG in the real world can have our queries running reliably and efficiently, while work to improve the query planner continues.
