3 ms·
> Many older DBAs, and their proteges distrust query planners because of bad experiences back in the 80's and early 90's. They are sure they can do a better jo
by tbrownaw 16y ago
> Many older DBAs, and their proteges distrust query planners because of bad experiences back in the 80's and early 90's. They are sure they can do a better job, even though they can't.
I remember having cases in the past year (on Oracle 10g) where adding hints helped substantially. Since it's impossible for me to ever do better than the optimizer, I guess this must mean I've gone nuts?
> Other DBAs are lazy or labor under unrealistic deadlines. Applying a query hint is often faster and easier than diagnosing the real reason the query has a bad plan.
Hints are evil and you should never use them, even though they make your job easier.
> Ignorance and weak software play a role too: good diagnostic tools and techniques for troubleshooting bad queries did not become available until relatively recently, and most DBAs still don't know how to use them.
Instead of just telling the optimizer what to do, you should have an extensive discussion with it and attempt to persuade it with concessions so that you don't hurt its feelings.
> The developers who work on the PostgreSQL not-for-profit database project, though, have the privilege of not implementing a bad idea just because a lot of people seem to want it.
Hints offend us, and we don't care if people find them useful.
> All that aside, there are those 0.1% of pathological cases where the query planner does The Wrong Thing even when it's patently obvious what the right thing is. In our community, that usually leads to patches and improvements in the query planner and the statistics system
Not supporting hints helps us extract useful code from our users. (hey, this is an aweseome idea, I need to think how to apply it to my projects...)
> Well, one thought is a system which would allow DBAs to selectively adjust the cost calculations for queries. For example, one which allowed you to put "SELECTIVITY 0.1" after a WHERE clause to tell the planner that despite what it thinks from its statistics, that set of criteria will give you 10% of the table. Even better would be a system of fudging the statistics on database objects, to allow DBAs to indicate (for example) that using a particular index is more costly than it appears because of the poor clustering of the data or because of the complex calculated expression it uses.
Hints are normally done the wrong way, and when we say we won't implement hints we really mean we won't do them that wrong way. We think we know the right way to do hints, and we're working on implementing it.
- Sessair 16y agoWhat arrogance. Perfect optimizers are an illusion. They are guaranteed to fail and to fail at the most inconvenient times. It is not only possible to do better than the optimizer on complex queries with hints its a given. Now that I know hints are not possible in PostgreSQL I will strictly curtail the kind of projects I will apply this RDBMS to. If you haven't found the need to use hints you have not explored the full range of what SQL is capable of (or worse yet use an ORM).