Re: WIP: Upper planner pathification

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: WIP: Upper planner pathification
Дата
Msg-id 17768.1457278371@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: WIP: Upper planner pathification  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: WIP: Upper planner pathification  (Amit Kapila <amit.kapila16@gmail.com>)
Re: WIP: Upper planner pathification  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Typo in psql-ref.sgml
Следующее
От: Chapman Flack
Дата:
Сообщение: character_not_in_repertoire vs. untranslatable_character