On Sun, Mar 6, 2016 at 9:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Amit Kapila <amit.kapil...@gmail.com> writes: > > On Sat, Mar 5, 2016 at 10:11 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> Is there some reason why hash and nestloop are safe but merge isn't? > > > I think it is because we consider to pushdown hash and nestloop to workers, > > but not merge join and the reason for not pushing mergejoin is that > > currently we don't have executor support for same, more work is needed > > there. > > If that's true, then mergejoin paths ought to be marked parallel-unsafe > explicitly (with a comment as to why), not just silently reduced to degree > zero in a manner that looks more like an oversight than anything > intentional. > > I also note that the regression tests pass with this patch and parallel > mode forced, which seems unlikely if allowing a parallel worker to execute > a join works for only two out of the three join types. And checking the > git history for nodeHashjoin.c, nodeHash.c, and nodeNestloop.c shows no > evidence that any of those files have been touched for parallel query, > so it's pretty hard to see a reason why those would work in parallel > queries but nodeMergejoin.c not. >
To make hash and nestloop work in parallel queries, we just push those nodes below gather node. Refer code paths match_unsorted_outer()->consider_parallel_nestloop() and hash_inner_and_outer()->try_partial_hashjoin_path(). Once the partial path for hash and nestloop gets generated in above code path, we generate gather path in function add_paths_to_joinrel()->generate_gather_paths(). You won't find the code to generate partial path for merge join. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
