On Fri, Dec 18, 2015 at 7.59 AM Robert Haas <robertmh...@gmail.com> Wrote,
> 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.
Yes, you are right, that create_gather_path() sets parallel_safe to false
unconditionally but whenever we are building a non partial path, that time
we should carry forward the parallel_safe state to its parent, and it seems
like that part is missing here..
I have done quick hack in create_nestloop_path and error is gone with this
change..
create_nestloop_path
{
pathnode->path.param_info =
get_joinrel_parampathinfo(root,
joinrel,
outer_path,
inner_path,
sjinfo,
required_outer,
&restrict_clauses);
pathnode->path.parallel_aware = false;
pathnode->path.parallel_safe = joinrel->consider_parallel; //may be
joinrel is parallel safe but particular path is unsafe, so we need take
this from inner_path and outer_path
// if any of the child path is parallel unsafe the mark parent as
parallel unsafe..
* pathnode->path.parallel_safe = (inner_path->parallel_safe &
outer_path->parallel_safe); *
}
New plan is attached in the mail.
with this change now we can see execution time is also become half (may be
because warning messages are gone)
> Do you have a self-contained test case that reproduces this, or any
> insight as to how it's happening here?
This is TPC-H benchmark case:
we can setup like this..
1. git clone https://tkej...@bitbucket.org/tkejser/tpch-dbgen.git
2. complie using make
3. ./dbgen –v –s 5
4. ./qgen
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Fri, Dec 18, 2015 at 7:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
> On Thu, Dec 17, 2015 at 12:33 AM, Amit Kapila <amit.kapil...@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
>
q7_parallel_new.out
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
