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

On Thu, Sep 24, 2020 at 7:57 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>
> On Tue, Sep 22, 2020 at 4:56 PM Greg Nancarrow <gregn4422@gmail.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.