Re: Multi-pass planner

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Multi-pass planner
Дата
Msg-id CAMkU=1wHbx9ewFEMQxO8UXG2G2fsVQOc=_A57-2ZnhAE0PYftA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multi-pass planner  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Список pgsql-hackers
On Thu, Apr 4, 2013 at 11:53 AM, Dimitri Fontaine <dimitri@2ndquadrant.fr> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> for estimate_worstcase_fraction.  So, when computing the cost of a
> path, we'd compute our current expected-case estimate, and also a
> worst-case estimate, and then compute the final cost as:

There also was the idea for the executor to be able to handle alternate
plans and some heuristic to determine that the actual cost of running a
plan is much higher than what's been estimated, so much so as to switch
to starting from scratch with the other plan instead.

Or even before it starts executing.  If the planner realizes the stakes are high enough, it could abandon its assumptions about how likely it is for a block to be in cache, and go do a little sampling of the cache and see.  To be effective it would probably have to sample the OS cache as well as the shared_buffers, which would certain complicate things and might not be portable.

Of course right now there is no explicit estimate about the cache hit rate at all, they are just implicitly built into other settings.  So those would probably need to be separated into true IO cost, and a default cache estimate to used when sampling is not warranted.

Cheers,

Jeff

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

Предыдущее
От: Claudio Freire
Дата:
Сообщение: Re: Multi-pass planner
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Multi-pass planner