Re: Parallel Seq Scan
| От | Amit Kapila |
|---|---|
| Тема | Re: Parallel Seq Scan |
| Дата | |
| Msg-id | CAA4eK1+LT07MqNdSr8yigE+fRKaYFy-q++GHyOcymEUr2irHDw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Parallel Seq Scan (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Parallel Seq Scan
|
| Список | pgsql-hackers |
On Thu, Sep 24, 2015 at 12:00 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > [ new patches ]
>
>
> It looks to me like there would be trouble if an initPlan or subPlan
> were kept below a Funnel, or as I guess we're going to call it, a
> Gather node. That's because a SubPlan doesn't actually have a pointer
> to the node tree for the sub-plan in it. It just has an index into
> PlannedStmt.subplans. But create_parallel_worker_plannedstmt sets the
> subplans list to NIL. So that's not gonna work. Now maybe there's no
> way for an initPlan or a subPlan to creep down under the funnel, but I
> don't immediately see what would prevent it.
>
>
> On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > [ new patches ]
>
>
> It looks to me like there would be trouble if an initPlan or subPlan
> were kept below a Funnel, or as I guess we're going to call it, a
> Gather node. That's because a SubPlan doesn't actually have a pointer
> to the node tree for the sub-plan in it. It just has an index into
> PlannedStmt.subplans. But create_parallel_worker_plannedstmt sets the
> subplans list to NIL. So that's not gonna work. Now maybe there's no
> way for an initPlan or a subPlan to creep down under the funnel, but I
> don't immediately see what would prevent it.
>
I think initPlan will work with the existing patches as we are always
executing it in master and then sending the result to workers. Refer
below code in funnel patch:
ExecFunnel()
{
..
+ /*
+ * Evaluate the InitPlan and pass the PARAM_EXEC params, so that
+ * values can be shared with worker backend. This is different from
+ * the way InitPlans are evaluated (lazy evaluation) at other places
+ * as instead of sharing the InitPlan to all the workers and let them
+ * execute, we pass the values which can be directly used by worker
+ * backends.
+ */
+ serialized_param_exec = ExecAndFormSerializeParamExec(econtext,
+ node->ss.ps.plan->lefttree->allParam);
}
For Subplan, as mentioned in yesterday's mail it is still to be dealt
by patch, but I think if we assign the subplans to the planned statement
we are passing to worker, it should work. Here we need to avoid un-safe
subplans to be pushed down, some more thoughts are required to see
what exactly needs to be done.
В списке pgsql-hackers по дате отправления: