Re: parallel joins, and better parallel explain

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: parallel joins, and better parallel explain
Дата
Msg-id CA+TgmobFQQnUhXmO3hhp3fWrzPkGhrdH1=uU=or31iLz7teSyg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: parallel joins, and better parallel explain  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: parallel joins, and better parallel explain  (Dilip Kumar <dilipbalaut@gmail.com>)
Список pgsql-hackers
On Thu, Dec 17, 2015 at 12:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> While looking at plans of Q5 and Q7, I have observed that Gather is
> pushed below another Gather node for which we don't have appropriate
> way of dealing.  I think that could be the reason why you are seeing
> the errors.

Uh oh.  That's not supposed to happen.  A GatherPath is supposed to
have parallel_safe = false, which should prevent the planner from
using it to form new partial paths.  Is this with the latest version
of the patch?  The plan output suggests that we're somehow reaching
try_partial_hashjoin_path() with inner_path being a GatherPath, but I
don't immediately see how that's possible, because
create_gather_path() sets parallel_safe to false unconditionally, and
hash_inner_and_outer() never sets cheapest_safe_inner to a path unless
that path is parallel_safe.

Do you have a self-contained test case that reproduces this, or any
insight as to how it's happening here?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Small fix in pg_rewind (redundant declaration)
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Small fix in pg_rewind (redundant declaration)