Re: parallel joins, and better parallel explain - Mailing list pgsql-hackers

From Robert Haas
Subject Re: parallel joins, and better parallel explain
Date
Msg-id CA+TgmobFQQnUhXmO3hhp3fWrzPkGhrdH1=uU=or31iLz7teSyg@mail.gmail.com
Whole thread Raw
In response to Re: parallel joins, and better parallel explain  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: parallel joins, and better parallel explain  (Dilip Kumar <dilipbalaut@gmail.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Small fix in pg_rewind (redundant declaration)
Next
From: Michael Paquier
Date:
Subject: Re: Small fix in pg_rewind (redundant declaration)