| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: parallelizing subplan execution (was: explain and PARAM_EXEC) |
| Date: | 2010-02-21 12:57:13 |
| Message-ID: | 407d949e1002210457x1a320980ta28d3b7cbfc89ee6@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Feb 21, 2010 at 3:25 AM, Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2010-02-21 13:46:10 | Re: scheduler in core |
| Previous Message | Robert Haas | 2010-02-21 12:37:50 | Re: Avoiding bad prepared-statement plans. |