Re: Parallel INSERT (INTO ... SELECT ...)

On Mon, Oct 12, 2020 at 5:36 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)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