Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Robert Haas]

On Thu, Aug 10, 2017 at 6:21 PM, Mark Dilger  wrote:
> That misses the point I was making.  I was suggesting a syntax where
> the caller promises to use all rows without stopping short, and the
> database performance problems of having a bunch of parallel workers
> suspended in mid query is simply the caller's problem if the caller does
> not honor the contract.

I understand.  My point is: that isn't sufficient to solve the
problem.  It's not a question of whether the caller uses all the
tuples, but whether the caller gets to do anything else while the
tuples are being generated, so to make it work, you'd have to first
run the parallel query to completion and buffer all the tuples in
memory and *only then* begin iterating over them and running the
user-supplied code.  You can't run the parallel query until it
produces a tuple, then do the code inside the loop, then run it until
the next tuple shows up, etc.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

> On Aug 10, 2017, at 11:20 AM, Robert Haas  wrote:
> 
> On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger  wrote:
>> I can understand this, but wonder if I could use something like
>> 
>> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
>> ...
>> END LOOP;
> 
> Actually, what you'd need is:
> 
> FOR I TOTALLY PROMISE TO USE ALL ROWS AND IT IS OK TO BUFFER THEM ALL
> IN MEMORY INSTEAD OF FETCHING THEM ONE AT A TIME FROM THE QUERY rec IN
> EXECUTE sql LOOP
> 
> Similarly, RETURN QUERY could be made to work with parallelism if we
> had RETURN QUERY AND IT IS OK TO BUFFER ALL THE ROWS IN MEMORY TWICE
> INSTEAD OF ONCE.
> 
> I've thought a bit about trying to make parallel query support partial
> execution, but it seems wicked hard.  The problem is that you can't
> let the main process do anything parallel-unsafe (e.g., currently,
> write any data) while the there are workers in existence, or things
> may blow up badly.  You could think about fixing that problem by
> having all of the workers exit cleanly when the query is suspended,
> and then firing up new ones when the query is resumed.  However, that
> presents two further problems: (1) having the workers exit cleanly
> when the query is suspended would cause wrong answers unless any
> tuples that the worker has implicitly claimed e.g. by taking a page
> from a parallel scan and returning only some of the tuples on it were
> somehow accounted for and (2) starting and stopping workers over and
> over would be bad for performance.  The second problem could be solved
> by having a persistent pool of workers that attach and detach instead
> of firing up new ones all the time, but that has a host of problems
> all of its own.  The first one would be desirable change for a bunch
> of reasons but is not easy for reasons that are a little longer than I
> feel like explaining right now.

That misses the point I was making.  I was suggesting a syntax where
the caller promises to use all rows without stopping short, and the
database performance problems of having a bunch of parallel workers
suspended in mid query is simply the caller's problem if the caller does
not honor the contract.  Maybe the ability to execute such queries would
be limited to users who are granted a privilege for doing so, and the DBA
can decide not to go around granting that privilege to anybody.
Certainly if this is being used from within a stored procedure, the DBA
can make certain only to use it in cases where there is no execution
path exiting the loop before completion, either because everything is
wrapped up with try/catch syntax and/or because the underlying query
does not call anything that might throw exceptions.

I'm not advocating that currently, as you responded to a somewhat old
email, so really I'm just making clear what I intended at the time.

mark



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Robert Haas]

On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger  wrote:
> I can understand this, but wonder if I could use something like
>
> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
> ...
> END LOOP;

Actually, what you'd need is:

FOR I TOTALLY PROMISE TO USE ALL ROWS AND IT IS OK TO BUFFER THEM ALL
IN MEMORY INSTEAD OF FETCHING THEM ONE AT A TIME FROM THE QUERY rec IN
EXECUTE sql LOOP

Similarly, RETURN QUERY could be made to work with parallelism if we
had RETURN QUERY AND IT IS OK TO BUFFER ALL THE ROWS IN MEMORY TWICE
INSTEAD OF ONCE.

I've thought a bit about trying to make parallel query support partial
execution, but it seems wicked hard.  The problem is that you can't
let the main process do anything parallel-unsafe (e.g., currently,
write any data) while the there are workers in existence, or things
may blow up badly.  You could think about fixing that problem by
having all of the workers exit cleanly when the query is suspended,
and then firing up new ones when the query is resumed.  However, that
presents two further problems: (1) having the workers exit cleanly
when the query is suspended would cause wrong answers unless any
tuples that the worker has implicitly claimed e.g. by taking a page
from a parallel scan and returning only some of the tuples on it were
somehow accounted for and (2) starting and stopping workers over and
over would be bad for performance.  The second problem could be solved
by having a persistent pool of workers that attach and detach instead
of firing up new ones all the time, but that has a host of problems
all of its own.  The first one would be desirable change for a bunch
of reasons but is not easy for reasons that are a little longer than I
feel like explaining right now.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

> On Jul 5, 2017, at 5:30 AM, Amit Kapila  wrote:
> 
> On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger  wrote:
>> 
>>> On Jul 3, 2017, at 10:25 PM, Amit Kapila  wrote:
>>> 
>>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs  wrote:
 On 30 June 2017 at 05:14, Amit Kapila  wrote:
 
> This is explained in section 15.2 [1], refer below para:
> "The query might be suspended during execution. In any situation in
> which the system thinks that partial or incremental execution might
> occur, no parallel plan is generated. For example, a cursor created
> using DECLARE CURSOR will never use a parallel plan. Similarly, a
> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
> use a parallel plan, because the parallel query system is unable to
> verify that the code in the loop is safe to execute while parallel
> query is active."
 
 Can you explain "unable to verify that the code in the loop is safe to
 execute while parallel query is active". Surely we aren't pushing code
 in the loop into the actual query, so the safety of command in the FOR
 loop has nothing to do with the parallel safety of the query.
 
 Please give an example of something that would be unsafe? Is that
 documented anywhere, README etc?
 
 FOR x IN query LOOP .. END LOOP
 seems like a case that would be just fine, since we're going to loop
 thru every row or break early.
 
>>> 
>>> It is not fine because we don't support partial execution support.  In
>>> above case, if the loop breaks, we can't break parallel query
>>> execution.  Now, I don't think it will impossible to support the same,
>>> but as of now, parallel subsystem doesn't have such a support.
>> 
>> I can understand this, but wonder if I could use something like
>> 
>> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
>> ...
>> END LOOP;
>> 
>> if I hacked the grammar up a bit.  Would the problem go away, or would
>> I still have problems when exceptions beyond my control get thrown inside
>> the loop?
>> 
> 
> I don't think it is just a matter of hacking grammar, internally we
> are using cursor fetch to fetch the rows and there we are passing some
> fixed number of rows to fetch which again is a killer to invoke the
> parallel query.

Is the risk that a RETURN will be executed within the loop block the only
risk that is causing parallel query to be disabled in these plpgsql loops?
If so, it seems that a plpgsql language syntax which created a loop that
disabled RETURN from within the loop body would solve the problem.  I
do not propose any such language extension.  It was just a thought
experiment.

Is there a conditional somewhere in the source that says, in effect, "if this
is a plpgsql loop, then disable parallel query"?  If so, and if I removed that
check such that parallel query would run in plpgsql loops, would I only
get breakage when I returned out of a loop?  Or would there be other
situations where that would break?

Thanks,

mark



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Amit Kapila]

On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger  wrote:
>
>> On Jul 3, 2017, at 10:25 PM, Amit Kapila  wrote:
>>
>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs  wrote:
>>> On 30 June 2017 at 05:14, Amit Kapila  wrote:
>>>
 This is explained in section 15.2 [1], refer below para:
 "The query might be suspended during execution. In any situation in
 which the system thinks that partial or incremental execution might
 occur, no parallel plan is generated. For example, a cursor created
 using DECLARE CURSOR will never use a parallel plan. Similarly, a
 PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
 use a parallel plan, because the parallel query system is unable to
 verify that the code in the loop is safe to execute while parallel
 query is active."
>>>
>>> Can you explain "unable to verify that the code in the loop is safe to
>>> execute while parallel query is active". Surely we aren't pushing code
>>> in the loop into the actual query, so the safety of command in the FOR
>>> loop has nothing to do with the parallel safety of the query.
>>>
>>> Please give an example of something that would be unsafe? Is that
>>> documented anywhere, README etc?
>>>
>>> FOR x IN query LOOP .. END LOOP
>>> seems like a case that would be just fine, since we're going to loop
>>> thru every row or break early.
>>>
>>
>> It is not fine because we don't support partial execution support.  In
>> above case, if the loop breaks, we can't break parallel query
>> execution.  Now, I don't think it will impossible to support the same,
>> but as of now, parallel subsystem doesn't have such a support.
>
> I can understand this, but wonder if I could use something like
>
> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
> ...
> END LOOP;
>
> if I hacked the grammar up a bit.  Would the problem go away, or would
> I still have problems when exceptions beyond my control get thrown inside
> the loop?
>

I don't think it is just a matter of hacking grammar, internally we
are using cursor fetch to fetch the rows and there we are passing some
fixed number of rows to fetch which again is a killer to invoke the
parallel query.

>  And if exception handling is a problem in the loop, are exceptions
> somehow not a problem in other parallel queries?
>

I don't see exceptions as a blocking factor to choose any parallel
query inside PL.  However, if you have something in mind, feel free to
share with some example?


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

> On Jul 3, 2017, at 10:25 PM, Amit Kapila  wrote:
> 
> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs  wrote:
>> On 30 June 2017 at 05:14, Amit Kapila  wrote:
>> 
>>> This is explained in section 15.2 [1], refer below para:
>>> "The query might be suspended during execution. In any situation in
>>> which the system thinks that partial or incremental execution might
>>> occur, no parallel plan is generated. For example, a cursor created
>>> using DECLARE CURSOR will never use a parallel plan. Similarly, a
>>> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
>>> use a parallel plan, because the parallel query system is unable to
>>> verify that the code in the loop is safe to execute while parallel
>>> query is active."
>> 
>> Can you explain "unable to verify that the code in the loop is safe to
>> execute while parallel query is active". Surely we aren't pushing code
>> in the loop into the actual query, so the safety of command in the FOR
>> loop has nothing to do with the parallel safety of the query.
>> 
>> Please give an example of something that would be unsafe? Is that
>> documented anywhere, README etc?
>> 
>> FOR x IN query LOOP .. END LOOP
>> seems like a case that would be just fine, since we're going to loop
>> thru every row or break early.
>> 
> 
> It is not fine because we don't support partial execution support.  In
> above case, if the loop breaks, we can't break parallel query
> execution.  Now, I don't think it will impossible to support the same,
> but as of now, parallel subsystem doesn't have such a support.

I can understand this, but wonder if I could use something like

FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
...
END LOOP;

if I hacked the grammar up a bit.  Would the problem go away, or would
I still have problems when exceptions beyond my control get thrown inside
the loop?  And if exception handling is a problem in the loop, are exceptions
somehow not a problem in other parallel queries?

Obviously I mean that syntax above in jest, but the question is in ernest.

Thanks,

mark



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Amit Kapila]

On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs  wrote:
> On 30 June 2017 at 05:14, Amit Kapila  wrote:
>
>> This is explained in section 15.2 [1], refer below para:
>> "The query might be suspended during execution. In any situation in
>> which the system thinks that partial or incremental execution might
>> occur, no parallel plan is generated. For example, a cursor created
>> using DECLARE CURSOR will never use a parallel plan. Similarly, a
>> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
>> use a parallel plan, because the parallel query system is unable to
>> verify that the code in the loop is safe to execute while parallel
>> query is active."
>
> Can you explain "unable to verify that the code in the loop is safe to
> execute while parallel query is active". Surely we aren't pushing code
> in the loop into the actual query, so the safety of command in the FOR
> loop has nothing to do with the parallel safety of the query.
>
> Please give an example of something that would be unsafe? Is that
> documented anywhere, README etc?
>
> FOR x IN query LOOP .. END LOOP
> seems like a case that would be just fine, since we're going to loop
> thru every row or break early.
>

It is not fine because we don't support partial execution support.  In
above case, if the loop breaks, we can't break parallel query
execution.  Now, I don't think it will impossible to support the same,
but as of now, parallel subsystem doesn't have such a support.

> Surely NO SCROLL and WITH HOLD cursors would work fine?
>

No, as of now they are not supported due to same reason (partial execution).

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Simon Riggs]

On 30 June 2017 at 05:14, Amit Kapila  wrote:

> This is explained in section 15.2 [1], refer below para:
> "The query might be suspended during execution. In any situation in
> which the system thinks that partial or incremental execution might
> occur, no parallel plan is generated. For example, a cursor created
> using DECLARE CURSOR will never use a parallel plan. Similarly, a
> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
> use a parallel plan, because the parallel query system is unable to
> verify that the code in the loop is safe to execute while parallel
> query is active."

Can you explain "unable to verify that the code in the loop is safe to
execute while parallel query is active". Surely we aren't pushing code
in the loop into the actual query, so the safety of command in the FOR
loop has nothing to do with the parallel safety of the query.

Please give an example of something that would be unsafe? Is that
documented anywhere, README etc?

FOR x IN query LOOP .. END LOOP
seems like a case that would be just fine, since we're going to loop
thru every row or break early.

Surely NO SCROLL and WITH HOLD cursors would work fine?

-- 
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Robert Haas]

On Fri, Jun 30, 2017 at 9:32 AM, Mark Dilger  wrote:
>> On Jun 29, 2017, at 8:55 PM, Mark Dilger  wrote:
>> Changing myfunc to create a temporary table, to execute the sql to populate
>> that temporary table, and to then loop through the temporary table's rows
>> fixes the problem.  For the real-world example where I hit this, that single
>> change decreases the runtime from 13.5 seconds to 2.5 seconds.
>
> Actually, this is wrong.  On further review, by the time I had changed the
> function definition, the data in the test server I was querying had likely 
> changed
> enough for the performance to change.  That duped me into thinking I had
> found a work-around.  I can no longer reproduce any performance improvement
> in this manner.

Also note that temporary tables are yet another thing that doesn't
work with parallel query yet.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

> On Jun 29, 2017, at 8:55 PM, Mark Dilger  wrote:
> 
> 
> Changing myfunc to create a temporary table, to execute the sql to populate
> that temporary table, and to then loop through the temporary table's rows
> fixes the problem.  For the real-world example where I hit this, that single
> change decreases the runtime from 13.5 seconds to 2.5 seconds.

Actually, this is wrong.  On further review, by the time I had changed the
function definition, the data in the test server I was querying had likely 
changed
enough for the performance to change.  That duped me into thinking I had
found a work-around.  I can no longer reproduce any performance improvement
in this manner.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

> On Jun 29, 2017, at 9:14 PM, Amit Kapila  wrote:
> 
> On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger  wrote:
>> Hackers,
>> 
>> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
>> allow a parallel plan if a portal will be returned.  This has the practical
>> consequence that a common coding practice (at least for me) of doing
>> something like:
>> 
>> create function myfunc(arg1 text, arg2 text) returns setof myfunctype as $$
>> declare
>>sql text;
>>result  myfunctype;
>> begin
>>-- unsafe interpolation, but this is just a code example
>>sql := 'select foo from bar where a = ' || arg1 || ' and b = ' || 
>> arg2;
>>for result in execute sql loop
>>return next result;
>>end loop;
>>return;
>> end;
>> $$ language plpgsql volatile;
>> 
>> can't run the generated 'sql' in parallel.  I think this is understandable, 
>> but
>> the documentation of this limitation in the sgml docs is thin.  Perhaps
>> someone who understands this limitation better than I do can document it?
>> 
> 
> This is explained in section 15.2 [1], refer below para:
> "The query might be suspended during execution. In any situation in
> which the system thinks that partial or incremental execution might
> occur, no parallel plan is generated. For example, a cursor created
> using DECLARE CURSOR will never use a parallel plan. Similarly, a
> PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
> use a parallel plan, because the parallel query system is unable to
> verify that the code in the loop is safe to execute while parallel
> query is active."
> 
> Check if that clarifies your doubts, otherwise, we might need to write
> something more so that it can be easier for users to understand.

That's what I was looking for.  I think I had trouble finding it since I was
using plpgsql (notice no slash) and "parallel worker" and so forth to try
to find it.  "PL/pgSQL" and "parallel query" are not terms I use, and did
not notice them buried a few sentences down in this paragraph.

Thanks for the citation.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Amit Kapila]

On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger  wrote:
> Hackers,
>
> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
> allow a parallel plan if a portal will be returned.  This has the practical
> consequence that a common coding practice (at least for me) of doing
> something like:
>
> create function myfunc(arg1 text, arg2 text) returns setof myfunctype as $$
> declare
> sql text;
> result  myfunctype;
> begin
> -- unsafe interpolation, but this is just a code example
> sql := 'select foo from bar where a = ' || arg1 || ' and b = ' || 
> arg2;
> for result in execute sql loop
> return next result;
> end loop;
> return;
> end;
> $$ language plpgsql volatile;
>
> can't run the generated 'sql' in parallel.  I think this is understandable, 
> but
> the documentation of this limitation in the sgml docs is thin.  Perhaps
> someone who understands this limitation better than I do can document it?
>

This is explained in section 15.2 [1], refer below para:
"The query might be suspended during execution. In any situation in
which the system thinks that partial or incremental execution might
occur, no parallel plan is generated. For example, a cursor created
using DECLARE CURSOR will never use a parallel plan. Similarly, a
PL/pgSQL loop of the form FOR x IN query LOOP .. END LOOP will never
use a parallel plan, because the parallel query system is unable to
verify that the code in the loop is safe to execute while parallel
query is active."

Check if that clarifies your doubts, otherwise, we might need to write
something more so that it can be easier for users to understand.

[1] - 
https://www.postgresql.org/docs/devel/static/when-can-parallel-query-be-used.html



-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

[Mark Dilger]

Hackers,

In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
allow a parallel plan if a portal will be returned.  This has the practical
consequence that a common coding practice (at least for me) of doing
something like:

create function myfunc(arg1 text, arg2 text) returns setof myfunctype as $$
declare
sql text;
result  myfunctype; 
begin
-- unsafe interpolation, but this is just a code example
sql := 'select foo from bar where a = ' || arg1 || ' and b = ' || arg2;
for result in execute sql loop
return next result;
end loop;
return;
end;
$$ language plpgsql volatile;

can't run the generated 'sql' in parallel.  I think this is understandable, but
the documentation of this limitation in the sgml docs is thin.  Perhaps
someone who understands this limitation better than I do can document it?
Changing myfunc to create a temporary table, to execute the sql to populate
that temporary table, and to then loop through the temporary table's rows
fixes the problem.  For the real-world example where I hit this, that single
change decreases the runtime from 13.5 seconds to 2.5 seconds.  This
makes sense to me, because doing it that way means pl_exec knows that
it won't be returning a portal for the executed sql, so the parallel plan is
still allowed.

Sorry to be a nag.  I'm only trying to help the next person who might
otherwise trip over this limitation.  Perhaps this belongs in section 15.3.4
or 42.5.4.

mark

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers