On Thu, Sep 10, 2015 at 4:16 AM, Robert Haas <
robertmhaas@gmail.com> wrote:
>
> On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila <
amit.kapila16@gmail.com> wrote:
> > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi <
kommi.haribabu@gmail.com>
> > wrote:
> >> With subquery, parallel scan is having some problem, please refer below.
> >>
> >> postgres=# explain analyze select * from test01 where kinkocord not in
> >> (select kinkocord from test02 where tenpocord = '001');
> >> ERROR: badly formatted node string "SUBPLAN :subLinkType 2 :testexpr"...
> >> CONTEXT: parallel worker, pid 32879
> >> postgres=#
> >
> > The problem here is that readfuncs.c doesn't have support for reading
> > SubPlan nodes. I have added support for some of the nodes, but it seems
> > SubPlan node also needs to be added. Now I think this is okay if the
> > SubPlan
> > is any node other than Funnel, but if Subplan contains Funnel, then each
> > worker needs to spawn other workers to execute the Subplan which I am
> > not sure is the best way. Another possibility could be store the results of
> > Subplan in some tuplestore or some other way and then pass those to workers
> > which again doesn't sound to be promising way considering we might have
> > hashed SubPlan for which we need to build a hashtable. Yet another way
> > could be for such cases execute the Filter in master node only.
>
> IIUC, there are two separate issues here:
>
Yes.
> 1. We need to have readfuncs support for all the right plan nodes.
> Maybe we should just bite the bullet and add readfuncs support for all
> plan nodes. But if not, we can add support for whatever we need.
>
> 2. I think it's probably a good idea - at least for now, and maybe
> forever - to avoid nesting parallel plans inside of other parallel
> plans. It's hard to imagine that being a win in a case like this, and
> it certainly adds a lot more cases to think about.
>
I also think that avoiding nested parallel plans is a good step forward.
