Re: parallelizing subplan execution (was: explain and PARAM_EXEC)

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: parallelizing subplan execution (was: explain and PARAM_EXEC)
Дата
Msg-id 407d949e1002210457x1a320980ta28d3b7cbfc89ee6@mail.gmail.com
обсуждение исходный текст
Ответ на Re: parallelizing subplan execution (was: explain and PARAM_EXEC)  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Sun, Feb 21, 2010 at 3:25 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> What kinds of things would be
> sensible to hand off in this way?  Well, you'd want to find nodes that
> are not likely to be repeatedly re-executed with different parameters,
> like subplans or inner-indexscans, because otherwise you'll get
> pipeline stalls handing the new parameters back and forth.  And you
> want to find nodes that are expensive for the same reason.

I think the case you want to handle is when you could execute a node
asynchronously. That is, if the rest of the plan can proceed without
the results until they are are ready.

The case that Oracle handled first and best was UNION ALL where each
child can be run in separate processes.



--
greg


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Avoiding bad prepared-statement plans.
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: scheduler in core