Re: [HACKERS] parallelize queries containing initplans

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Haribabu Kommi <kommi.haribabu@gmail.com>, Kuntal Ghosh <kuntalghosh.2007@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-14T16:00:14Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 14, 2017 at 12:00 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> 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.

Yeah, I'm sure it is.  I have a vague recollection that there might be
existing regression test cases exercising such things, though I won't
swear to that.  The "orderstest" bit in subselect.sql looks like it
might be meant to do that...

			regards, tom lane


Commits

  1. Pass InitPlan values to workers via Gather (Merge).

  2. Track in the plan the types associated with PARAM_EXEC parameters.

  3. Force rescanning of parallel-aware scan nodes below a Gather[Merge].