pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
To: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Oddity with parallel safety test for scan/join target in grouping_planner
Date: Tue, 26 Feb 2019 21:25:34 +0900
Message-ID: <5C75303E.8020303@lab.ntt.co.jp> (raw)

Hi hackers,

While working on [1], I noticed $Subject, that is:

        /*
         * If we have grouping or aggregation to do, the topmost scan/join
         * plan node must emit what the grouping step wants; otherwise, it
         * should emit grouping_target.
         */
        have_grouping = (parse->groupClause || parse->groupingSets ||
                         parse->hasAggs || root->hasHavingQual);
        if (have_grouping)
        {
            scanjoin_target = make_group_input_target(root, final_target);
-->         scanjoin_target_parallel_safe =
                is_parallel_safe(root, (Node *) grouping_target->exprs);
        }
        else
        {
            scanjoin_target = grouping_target;
            scanjoin_target_parallel_safe = grouping_target_parallel_safe;
        }

The parallel safety of the final scan/join target is determined from the
grouping target, not that target, which would cause to generate inferior
parallel plans as shown below:

pgbench=# explain verbose select aid+bid, sum(abalance), random() from
pgbench_accounts group by aid+bid;
                                                 QUERY PLAN
------------------------------------------------------------------------------------------------------------
 GroupAggregate  (cost=137403.01..159903.01 rows=1000000 width=20)
   Output: ((aid + bid)), sum(abalance), random()
   Group Key: ((pgbench_accounts.aid + pgbench_accounts.bid))
   ->  Sort  (cost=137403.01..139903.01 rows=1000000 width=8)
         Output: ((aid + bid)), abalance
         Sort Key: ((pgbench_accounts.aid + pgbench_accounts.bid))
         ->  Gather  (cost=10.00..24070.67 rows=1000000 width=8)
               Output: (aid + bid), abalance
               Workers Planned: 2
               ->  Parallel Seq Scan on public.pgbench_accounts
(cost=0.00..20560.67 rows=416667 width=12)
                     Output: aid, bid, abalance
(11 rows)

The final scan/join target {(aid + bid), abalance} is definitely
parallel safe, but the target evaluation isn't parallelized across
workers, which is not good.  Attached is a patch for fixing this.

Best regards,
Etsuro Fujita

[1] https://commitfest.postgresql.org/22/1950/

Attachments:

target_parallel_safe.patch (text/x-patch, 590B) download *** a/src/backend/optimizer/plan/planner.c --- b/src/backend/optimizer/plan/planner.c *************** *** 1989,1995 **** grouping_planner(PlannerInfo *root, bool inheritance_update, { scanjoin_target = make_group_input_target(root, final_target); scanjoin_target_parallel_safe = ! is_parallel_safe(root, (Node *) grouping_target->exprs); } else { --- 1989,1995 ---- { scanjoin_target = make_group_input_target(root, final_target); scanjoin_target_parallel_safe = ! is_parallel_safe(root, (Node *) scanjoin_target->exprs); } else {

view thread (12+ messages)  latest in thread

Message-ID: <5C75303E.8020303@lab.ntt.co.jp>
Permalink:  ../5C75303E.8020303@lab.ntt.co.jp/
Also on:    postgresql.org/message-id/5C75303E.8020303@lab.ntt.co.jp

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: fujita.etsuro@lab.ntt.co.jp
  Subject: Re: Oddity with parallel safety test for scan/join target in grouping_planner
  In-Reply-To: <5C75303E.8020303@lab.ntt.co.jp>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox