Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism |
Дата | |
Msg-id | 20170601164650.o4vamwuruaat343e@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] COPY (query) TO ... doesn't allow parallelism
|
Список | pgsql-hackers |
On 2017-06-01 21:37:56 +0530, Amit Kapila wrote: > On Thu, Jun 1, 2017 at 9:34 PM, Andres Freund <andres@anarazel.de> wrote: > > On 2017-06-01 21:23:04 +0530, Amit Kapila wrote: > >> On a related note, I think it might be better to have an > >> IsInParallelMode() check in this case as we have at other places. > >> This is to ensure that if this command is invoked via plpgsql function > >> and that function runs is the parallel mode, it will act as a > >> safeguard. > > > > Hm? Which other places do it that way? Isn't standard_planner() > > centralizing such a check? > > > > heap_insert->heap_prepare_insert, heap_update, heap_delete, etc. Those aren't comparable, they're not invoking the planner - and all the places that set PARALLEL_OK don't check for it. The relevant check for planning is in standard_planner(). - Andres
В списке pgsql-hackers по дате отправления: