Re: Parallel Seq Scan

On Wed, Sep 9, 2015 at 11:07 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Wed, Sep 9, 2015 at 11:47 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)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:

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.

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