Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan
Дата
Msg-id CA+TgmoZvR9SP5mzH1k7MYrv3y1z4dWoJGz2z2SU-Qo1B7LrdgA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #16040: PL/PGSQL RETURN QUERY statement never uses a parallel plan  (Marc Bachmann <marc.brookman@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: PG Bug reporting form
Дата:
Сообщение: BUG #16492: DROP VIEW IF EXISTS error
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: BUG #16492: DROP VIEW IF EXISTS error