Re: parallelizing subplan execution (was: explain and PARAM_EXEC) - Mailing list pgsql-hackers

From Greg Stark
Subject Re: parallelizing subplan execution (was: explain and PARAM_EXEC)
Date
Msg-id 407d949e1002210457x1a320980ta28d3b7cbfc89ee6@mail.gmail.com
Whole thread Raw
In response to Re: parallelizing subplan execution (was: explain and PARAM_EXEC)  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Avoiding bad prepared-statement plans.
Next
From: Andrew Dunstan
Date:
Subject: Re: scheduler in core