Re: [HACKERS] parallelize queries containing initplans

On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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