Message-ID: <5C765E99.9070202@lab.ntt.co.jp>
Date: Wed, 27 Feb 2019 18:55:37 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: Oddity with parallel safety test for scan/join target in
 grouping_planner
References: <5C75303E.8020303@lab.ntt.co.jp>
In-Reply-To: <5C75303E.8020303@lab.ntt.co.jp>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
To: Pg Hackers <pgsql-hackers@postgresql.org>
Precedence: bulk

(2019/02/26 21:25), Etsuro Fujita wrote:
> 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.

I added this to the upcoming commitfest.

Best regards,
Etsuro Fujita