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 по дате отправления:

Предыдущее
От: Greg Stark
Дата:
Сообщение: Re: Needed function IF(expr, expr, expr)
Следующее
От: elein
Дата:
Сообщение: Re: Trunc in Postgres