Re: Parallel INSERT (INTO ... SELECT ...)
От | Greg Nancarrow |
---|---|
Тема | Re: Parallel INSERT (INTO ... SELECT ...) |
Дата | |
Msg-id | CAJcOf-c+j=iXFQE9NXOQV4_Xxw8BdRk1j9ewz=tDt0+fGFvXHA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel INSERT (INTO ... SELECT ...) (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: Parallel INSERT (INTO ... SELECT ...)
|
Список | pgsql-hackers |
On Mon, Oct 12, 2020 at 5:36 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > I have not thought about this yet but I don't understand your > > proposal. How will you set it only for the scope of Gather (Merge)? > > The execution of the Gather node will be interleaved with the Insert > > node, basically, you fetch a tuple from Gather, and then you need to > > Insert it. Can you be a bit more specific on what you have in mind for > > this? > > > > One more thing I would like to add here is that we can't exit > parallel-mode till the workers are running (performing the scan or > other operation it is assigned with) and shared memory is not > destroyed. Otherwise, the leader can perform un-safe things like > assigning new commandsids or probably workers can send some error for > which the leader should still be in parallel-mode. So, considering > this I think we need quite similar checks (similar to parallel > inserts) to make even the Select part parallel for Inserts. If we do > that then you won't face many of the problems you mentioned above like > executing triggers that contain parallel-unsafe stuff. I feel still it > will be beneficial to do this as it will cover cases like Insert with > GatherMerge underneath it which would otherwise not possible. > Yes, I see what you mean, exiting parallel-mode can't be done safely where I had hoped it could, so looks like, even for making just the Select part of Insert parallel, I need to add checks (along the same lines as for Parallel Insert) to avoid the parallel Select in certain potentially-unsafe cases. Regards, Greg Nancarrow Fujitsu Australia
В списке pgsql-hackers по дате отправления: