> On Fri, Aug 7, 2015 at 2:15 PM, Kouhei Kaigai <kaigai@ak.jp.nec.com> wrote: > > > > Sure, that is what we should do, however the tricky part would be when > the path for doing local scan is extremely cheaper than path for parallel > scan for one of the child nodes. For such cases, pulling up Funnel-node > can incur more cost. I think some of the other possible ways to make this > work could be to extend Funnel so that it is capable of executing both parallel > and non-parallel nodes, have a new Funnel like node which has such a > capability. >
I think it is job of (more intelligent) planner but not in the first version. If subplans of Append are mixture of nodes which has or does not have worth of parallel execution, we will be able to arrange the original form:
Append + Scan on rel1 (large) + Scan on rel2 (large) + Scan on rel3 (middle) + Scan on rel4 (tiny) + Scan on rel5 (tiny)
to Funnel aware form, but partially:
Append + Funnel | + Scan on rel1 (large) | + Scan on rel2 (large) | + Scan on rel3 (large) + Scan on rel4 (tiny) + Scan on rel5 (tiny)
This is exactly what I have in mind.
Here is one other issue I found. Existing code assumes a TOC segment has only one contents per node type, so it uses pre-defined key (like PARALLEL_KEY_SCAN) per node type, however, it is problematic if we put multiple PlannedStmt or PartialSeqScan node on a TOC segment.
We have few keys in parallel-seq-scan patch
(PARALLEL_KEY_TUPLE_QUEUE and PARALLEL_KEY_INST_INFO) for
which multiple structures are shared between master and worker backends.
Check if something similar can work for your use case.
