On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > I think this would have been a matter of concern if we use initplans > below Gather/Gather Merge. The patch uses initplans which are between > current query level and root. So, I think we don't need to reevaluate > such parameters. Let us try to see it via example: > > > QUERY PLAN > ---------------------------------------------------------------------------------------- > Aggregate (cost=62.08..62.08 rows=1 width=8) > InitPlan 1 (returns $1) > -> Finalize Aggregate (cost=20.64..20.65 rows=1 width=8) > -> Gather (cost=20.63..20.64 rows=2 width=8) > Workers Planned: 2 > -> Partial Aggregate (cost=20.63..20.64 rows=1 width=8) > -> Parallel Seq Scan on t3 (cost=0.00..18.50 > rows=850 width=4) > -> Hash Join (cost=20.75..41.42 rows=1 width=4) > Hash Cond: (t1.j = t2.j) > -> Gather (cost=0.00..20.63 rows=10 width=12) > Workers Planned: 2 > Params Evaluated: $1 > -> Parallel Seq Scan on t1 (cost=0.00..20.63 rows=4 width=12) > Filter: (k = $1) > -> Hash (cost=20.63..20.63 rows=10 width=8) > -> Gather (cost=0.00..20.63 rows=10 width=8) > Workers Planned: 2 > Params Evaluated: $1 > -> Parallel Seq Scan on t2 (cost=0.00..20.63 > rows=4 width=8) > Filter: (k = $1) > (20 rows) > > > Now, here even if initplan would have been an undirect correlated > plan, it wouldn't have been a problem, because we don't need to > reevaluate it for Gather node below Hash. > > Am I missing something? Do you have some test or shape of the plan in > mind which can cause a problem?
The problem would happen if the plan for InitPlan $1 in the above example itself referenced a parameter from an upper query level, and the value of that parameter changed, and then this section of the plan tree was rescanned. I'm not sure I can write a query like that off-hand, but I think it's possible to do so. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company