Re: Parallel INSERT (INTO ... SELECT ...) - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CA+hUKG+pRgX7tJZMgTGYeKmgMYWspUkmik6-C8CktNsCfZEOFA@mail.gmail.com
Whole thread Raw
In response to Parallel INSERT (INTO ... SELECT ...)  (Greg Nancarrow <gregn4422@gmail.com>)
Responses Re: Parallel INSERT (INTO ... SELECT ...)  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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).



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)
Next
From: Amit Kapila
Date:
Subject: Re: Parallel INSERT (INTO ... SELECT ...)