Re: Parallel Seq Scan

On Thu, Sep 17, 2015 at 2:54 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> As per my understanding, what you have done there will not prohibit such
> cases.
>
> + * For now, we don't try to use parallel mode if we're running inside
> + * a parallel worker. We might eventually be able to relax this
> + * restriction, but for now it seems best not to have parallel workers
> + * trying to create their own parallel workers.
> + */
> + glob->parallelModeOK = (cursorOptions & CURSOR_OPT_PARALLEL_OK) != 0 &&
> + IsUnderPostmaster && dynamic_shared_memory_type != DSM_IMPL_NONE &&
> + parse->commandType == CMD_SELECT && !parse->hasModifyingCTE &&
> + parse->utilityStmt == NULL && !IsParallelWorker() &&
> + !contain_parallel_unsafe((Node *) parse);
>
>
> IIUC, your are referring to !IsParallelWorker() check in above code. If
> yes,
> then I think it won't work because we generate the plan in master backend,
> parallel worker will never exercise this code. I have tested it as well
> with
> below example and it still generates SubPlan as Funnel.

You're right. That's still a good check, because some function called
in the worker might try to execute a query all of its own, but it
doesn't prevent the case you are talking about.

> Here the subplan is generated before the top level plan and while generation
> of subplan we can't predict whether it is okay to generate it as Funnel or
> not,
> because it might be that top level plan is non-Funnel. Also if such a
> subplan
> is actually an InitPlan, then we are safe (as we execute the InitPlans in
> master backend and then pass the result to parallel worker) even if top
> level
> plan is Funnel. I think the place where we can catch this is during the
> generation of Funnel path, basically we can evaluate if any nodes beneath
> Funnel node has 'filter' or 'targetlist' as another Funnel node, then we
> have
> two options to proceed:
> a. Mark such a filter or target list as non-pushable which will indicate
> that
> they need to be executed only in master backend. If we go with this
> option, then we have to make Funnel node capable of evaluating Filter
> and Targetlist which is not a big thing.
> b. Don't choose the current path as Funnel path.
>
> I prefer second one as that seems to be simpler as compare to first and
> there doesn't seem to be much benefit in going by first.
>
> Any better ideas?

I haven't studied the planner logic in enough detail yet to have a
clear opinion on this. But what I do think is that this is a very
good reason why we should bite the bullet and add outfuncs/readfuncs
support for all Plan nodes. Otherwise, we're going to have to scan
subplans for nodes we're not expecting to see there, which seems
silly. We eventually want to allow all of those nodes in the worker
anyway.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company