Re: Shouldn't we have a way to avoid "risky" plans?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Shouldn't we have a way to avoid "risky" plans?
Дата
Msg-id 2951.1301062330@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Shouldn't we have a way to avoid "risky" plans?  (Vitalii Tymchyshyn <tivv00@gmail.com>)
Ответы Re: Shouldn't we have a way to avoid "risky" plans?  (Vitalii Tymchyshyn <tivv00@gmail.com>)
Список pgsql-performance
Vitalii Tymchyshyn <tivv00@gmail.com> writes:
> 24.03.11 20:41, Merlin Moncure �������(��):
>> ISTM if you add statistics miss and 'risk margin' to the things the
>> planner would have to consider while generating a plan, you are
>> greatly increasing the number of plan paths that would have to be
>> considered for any non trivial query.

> Why so? I simply change cost estimation functions. This won't change
> number of pathes.

If you have multiple figures of merit, that means you have to keep more
paths, with consequent slowdown when it comes to choosing which path to
use at higher join levels.

As an example, we used to keep only the paths with best total cost.
When we started to optimize LIMIT, we had to keep around paths with best
startup cost too, in case that made for the best combined result at a
higher join level.  If you're going to consider "risk" while choosing
paths, that means you'll start keeping paths you would have discarded
before, while not necessarily getting rid of any other paths.  The only
way to avoid that would be to have a completely brain-dead notion of
risk that wasn't affected by how the path is used at a higher join
level, and I'm pretty sure that that wouldn't solve anybody's problem.

Any significant expansion of the planner's fundamental cost model *will*
make it slower.  By a lot.  Rather than going into this with fantasies
of "it won't cost anything", you should be worrying about how to keep
the speed penalty to factor-of-two rather than factor-of-ten.

            regards, tom lane

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

Предыдущее
От: Shaun Thomas
Дата:
Сообщение: Re: Why Index is not used
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Shouldn't we have a way to avoid "risky" plans?