Re: Optimizer picks an ineffient plan
От | Stephan Szabo |
---|---|
Тема | Re: Optimizer picks an ineffient plan |
Дата | |
Msg-id | 20030906122309.C20687-100000@megazone.bigpanda.com обсуждение исходный текст |
Ответ на | Re: Optimizer picks an ineffient plan ("Relaxin" <noname@spam.com>) |
Список | pgsql-general |
On Fri, 5 Sep 2003, Relaxin wrote: > And your argument about how it will increase other queries is pointless to > me. Will you still stand by this argument when the PG folks find a situation > where the optimizer creates a terrible plan and the only way to fix is to > add additional logic, based on what you are saying, it's not worth it > because it could add .001 seconds of additional processing. I've tried to say that you need to balance the cost of the optimization against its potential gain in the cases it helps, the frequency of those cases, the ability to solve the problems other ways and against the development time that is used in it. There isn't a push button with two states, best and not best. When you want to argue about an optimization you should think about: a) What does the optimization actually mean (actual specification, not vague words) b) What cases is the optimization legal for (doesn't change results, doesn't violate spec, etc) c) What cases does the optimization help (as separate from b in that some cases may not actually be faster but the optimization is legal) d) What is the gain over the cases that the optimization helps e) What is the penalty over the cases that the optimization does not help If someone feels strongly about it or feels that they have the time, they can (and should be generally promoted to) attempt the optimization. If the optimization is not expensive or has better than expected gains or good side effects, it's likely to get accepted.
В списке pgsql-general по дате отправления: