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