On Thu, Sep 10, 2015 at 4:16 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi < kommi.harib...@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. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
