Re: Overriding the optimizer

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Overriding the optimizer
Дата
Msg-id 18537.1134692629@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
Ответы Re: Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
Re: Overriding the optimizer  ("Craig A. James" <cjames@modgraph-usa.com>)
Список pgsql-performance
"Craig A. James" <cjames@modgraph-usa.com> writes:
> I see this over and over.  Tweak the parameters to "force" a certain
> plan, because there's no formal way for a developer to say, "I know
> the best plan."

I think you've misunderstood those conversations entirely.  The point
is not to force the planner into a certain plan, it is to explore what's
going on with a view to understanding why the planner isn't making a
good choice, and thence hopefully improve the planner in future.  (Now,
that's not necessarily what the user with an immediate problem is
thinking, but that's definitely what the developers are thinking.)

> There isn't a database in the world that is as smart as a developer,

People who are convinced they are smarter than the machine are often
wrong ;-).  If we did put in the nontrivial amount of work needed to
have such a facility, it would probably get abused more often than it
was used correctly.  I'd rather spend the work on making the planner
better.

This discussion has been had before (many times) ... see the -hackers
archives for detailed arguments.  The one that carries the most weight
in my mind is that planner hints embedded in applications will not adapt
to changing circumstances --- the plan that was best when you designed
the code might not be best today.

            regards, tom lane

В списке pgsql-performance по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How much expensive are row level statistics?
Следующее
От: Christopher Kings-Lynne
Дата:
Сообщение: Re: Overriding the optimizer