Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan - Mailing list pgsql-bugs

From Robert Haas
Subject Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan
Date
Msg-id CA+TgmoZvR9SP5mzH1k7MYrv3y1z4dWoJGz2z2SU-Qo1B7LrdgA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan
List pgsql-bugs
On Sat, Mar 21, 2020 at 11:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I think that the latter restriction is probably sane, because we don't
> want to suspend execution of a parallel query while we've got worker
> processes waiting.

Right.

> And there might be some implementation restrictions
> lurking under it too --- that's not a part of the code I know in any
> detail.

There are. When you EnterParallelMode(), various normally-permissible
options are restricted and will error out (e.g. updating your snapshot
or command ID). Parallel query's not safe unless you remain in
parallel mode from start to finish, but that means you can't let
control escape into code that might do arbitrary things. That in a
nutshell is why the cursor restriction is there.

This is a heck of a nice improvement. Thanks for working on it.

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



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16492: DROP VIEW IF EXISTS error
Next
From: "David G. Johnston"
Date:
Subject: Re: BUG #16492: DROP VIEW IF EXISTS error