Re: WIP: Upper planner pathification - Mailing list pgsql-hackers

From Tom Lane
Subject Re: WIP: Upper planner pathification
Date
Msg-id 17768.1457278371@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: Upper planner pathification  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: WIP: Upper planner pathification  (Amit Kapila <amit.kapila16@gmail.com>)
Re: WIP: Upper planner pathification  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Amit Kapila <amit.kapila16@gmail.com> writes:
> On Sat, Mar 5, 2016 at 10:11 PM, Tom Lane <tgl@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.

I still say the code as it stands is merely a copy-and-pasteo.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Typo in psql-ref.sgml
Next
From: Chapman Flack
Date:
Subject: character_not_in_repertoire vs. untranslatable_character