Re: parallel joins, and better parallel explain

On Fri, Dec 18, 2015 at 7.59 AM Robert Haas <robertmhaas(at)gmail(dot)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://tkejser(at)bitbucket(dot)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 <robertmhaas(at)gmail(dot)com> wrote:

> 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
>