Re: parallelize queries containing initplans
Kuntal Ghosh <kuntalghosh.2007@gmail.com>
From: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
To: Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-09T10:54:10Z
Lists: pgsql-hackers
On Wed, Aug 9, 2017 at 10:24 AM, Haribabu Kommi <kommi.haribabu@gmail.com> wrote: > > I tested the latest patch and the parallel plan is getting choose for most > of > the init plans. > Thanks for testing. > For the following query the parallel plan is not chosen. The query contains > an init plan that refer the outer node. > > postgres=# explain analyze select * from t1 where t1.i in (select t2.i from > t2 where t1.k = (select max(k) from t3 where t3.i=t1.i)); > QUERY PLAN > --------------------------------------------------------------------------------------------------------------------- > Seq Scan on t1 (cost=0.00..22426.28 rows=448 width=12) (actual > time=8.335..132.557 rows=2 loops=1) > Filter: (SubPlan 2) > Rows Removed by Filter: 894 > SubPlan 2 > -> Result (cost=16.27..31.26 rows=999 width=4) (actual > time=0.146..0.146 rows=0 loops=896) > One-Time Filter: (t1.k = $1) > InitPlan 1 (returns $1) > -> Aggregate (cost=16.25..16.27 rows=1 width=4) (actual > time=0.145..0.145 rows=1 loops=896) > -> Seq Scan on t3 (cost=0.00..16.25 rows=2 width=4) > (actual time=0.131..0.144 rows=0 loops=896) > Filter: (i = t1.i) > Rows Removed by Filter: 900 > -> Seq Scan on t2 (cost=16.27..31.26 rows=999 width=4) (actual > time=0.012..0.013 rows=10 loops=2) > Planning time: 0.272 ms > Execution time: 132.623 ms > (14 rows) > An observation is that the filter at Result node can't be pushed down to the sequential scan on t2 because the filter is on t1. So, it has to scan the complete t2 relation and send all the tuple to upper node, a worst case for parallelism. Probably, this is the reason the optimizer doesn't pick parallel plan for the above case. Just for clarification, do you see any changes in the plan after forcing parallelism(parallel_tuple_cost, parallel_setup_cost, min_parallel_table_scan_size=0)? -- Thanks & Regards, Kuntal Ghosh EnterpriseDB: http://www.enterprisedb.com
Commits
-
Pass InitPlan values to workers via Gather (Merge).
- e89a71fb449a 11.0 landed
-
Track in the plan the types associated with PARAM_EXEC parameters.
- e64861c79bda 11.0 landed
-
Force rescanning of parallel-aware scan nodes below a Gather[Merge].
- 7df2c1f8daeb 11.0 cited