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

On Thu, Sep 24, 2020 at 7:57 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Tue, Sep 22, 2020 at 4:56 PM Greg Nancarrow <gregn4422(at)gmail(dot)com> wrote:
> > Gather (cost=0.00..16.00 rows=9999 width=12) (actual
> > time=69.870..70.310 rows=0 loops=1)
> > Workers Planned: 5
> > Workers Launched: 5
> > -> Parallel Insert on primary_tbl (cost=0.00..16.00 rows=500
> > width=12) (actual time=59.948..59.949 rows=0 loops=6)
>
> Nice. I took it for a quick spin. I was initially surprised to see
> Gather. I suppose I thought that Parallel {Insert|Update|Delete}
> might be a top level node itself, because in such a plan there is no
> need to gather tuples per se. I understand exactly why you have it
> that way though: Gather is needed to control workers and handle their
> errors etc, and we don't want to have to terminate parallelism anyway
> (thinking of some kind of plan with multiple write subqueries).
>

I have not checked the patch but I guess if we parallelise Inserts
with Returning then isn't it better to have Gather node above Parallel
Inserts?

--
With Regards,
Amit Kapila.