Re: Parallel Seq Scan

On Thu, Sep 17, 2015 at 4:44 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Sep 17, 2015 at 2:54 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
>
>
> > 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.
>

makes sense to me. There are 39 plan nodes and it seems we have
support for all of them in outfuncs and needs to add for most of them
in readfuncs.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com