From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: parallel joins, and better parallel explain |
Date: | 2015-12-18 02:29:13 |
Message-ID: | CA+TgmobFQQnUhXmO3hhp3fWrzPkGhrdH1=uU=or31iLz7teSyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Dec 17, 2015 at 12:33 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-12-18 02:51:36 | Re: Small fix in pg_rewind (redundant declaration) |
Previous Message | Tom Lane | 2015-12-18 01:22:26 | Re: Small fix in pg_rewind (redundant declaration) |