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
-
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