Re: Determine parallel-safety of partition relations for Inserts

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Determine parallel-safety of partition relations for Inserts
Дата
Msg-id CAA4eK1LK=E97z=TkKN1e5JMaxPhV0Z_YQJWZboSDiJkSw6NOrg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Determine parallel-safety of partition relations for Inserts  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Determine parallel-safety of partition relations for Inserts  (Amit Langote <amitlangote09@gmail.com>)
Список pgsql-hackers
On Fri, Jan 15, 2021 at 6:45 PM Amit Langote <amitlangote09@gmail.com> wrote:
>
> On Fri, Jan 15, 2021 at 9:59 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > We want to do this for Inserts where only Select can be parallel and
> > Inserts will always be done by the leader backend. This is actually
> > the case we first want to implement.
>
> Sorry, I haven't looked at the linked threads and the latest patches
> there closely enough yet, so I may be misreading this, but if the
> inserts will always be done by the leader backend as you say, then why
> does the planner need to be checking the parallel safety of the
> *target* table's expressions?
>

The reason is that once we enter parallel-mode we can't allow
parallel-unsafe things (like allocation of new CIDs, XIDs, etc.). We
enter the parallel-mode at the beginning of the statement execution,
see ExecutePlan(). So, the Insert will be performed in parallel-mode
even though it happens in the leader backend. It is not possible that
we finish getting all the tuples from the gather node first and then
start inserting. Even, if we somehow find something to make this work
anyway the checks being discussed will be required to make inserts
parallel (where inserts will be performed by workers) which is
actually the next patch in the thread I mentioned in the previous
email.

Does this answer your question?

-- 
With Regards,
Amit Kapila.



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Occasional tablespace.sql failures in check-world -jnn
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit