"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > In the last couple weeks I too have been thinking about planner hints. > Assuming I have read your post correctly, the issue I see with this idea is > that, in most cases, there won't be much of a difference between adding an > arbitrary cost value to each type of node and disabling it completely. > Also, by fiddling with an arbitrary cost the user may introduce a lot of > variation into the planner which may actually result in worse query plans.
Which is pretty much exactly the problem with "planner hints", too. I've resisted that suggestion in the past and will continue to do so, because hints are accidents waiting to happen. Even if the hint is right today for your current Postgres version and current data distribution, it's likely not to be right further down the road --- but once the hint is embedded in your application, how often are you going to revisit it? As an example, a hint forcing the planner to use an indexscan with a particular index might have been a great idea in PG 8.0 and a lousy idea in 8.1, because it would prevent substitution of a possibly-far-better bitmap indexscan. The enable_foo switches are debug aids, not something you are expected to fool with for production purposes, and the same would be true of Neil's suggested multipliers. While I don't feel any strong need for variable multipliers, they'd be a small enough incremental amount of work that the suggestion doesn't require a lot of supporting argument. Adding a planner hint facility would be several orders of magnitude more work, and it would be taking the system in a design direction that I think is fundamentally misguided. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org