Re: parallel joins, and better parallel explain
| От | Dilip Kumar |
|---|---|
| Тема | Re: parallel joins, and better parallel explain |
| Дата | |
| Msg-id | CAFiTN-uCDnVtk8Cfniin_RsC=L3a3qET3mtEdMZ_sbDvx=QxUA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: parallel joins, and better parallel explain (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: parallel joins, and better parallel explain
(Robert Haas <robertmhaas@gmail.com>)
|
| Список | pgsql-hackers |
On Fri, Dec 18, 2015 at 7.59 AM Robert Haas <robertmhaas@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..> 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.
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);
}
> Do you have a self-contained test case that reproduces this, or any
> insight as to how it's happening here?
> insight as to how it's happening here?
This is TPC-H benchmark case:
2. complie using make
3. ./dbgen –v –s 5
3. ./dbgen –v –s 5
4. ./qgen
On Fri, Dec 18, 2015 at 7:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
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?
Вложения
В списке pgsql-hackers по дате отправления: