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

On Mon, Oct 12, 2020 at 9:01 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Oct 12, 2020 at 6:51 AM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> >
>
> > Let me know your thoughts on how to deal with these issues.
> > Can you see a problem with only having parallel-mode set for scope of
> > Gather/GatherMerge, or do you have some other idea?
> >
>
> 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.

--
With Regards,
Amit Kapila.