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

From Greg Nancarrow
Subject Re: Parallel INSERT (INTO ... SELECT ...)
Date
Msg-id CAJcOf-c3mpV_Zyk8YNfsofzP2B2xDvKCqpPJE5egyjwYp4+HJw@mail.gmail.com
Whole thread Raw
In response to Re: Parallel INSERT (INTO ... SELECT ...)  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Thu, Sep 24, 2020 at 12:38 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> 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?
>

This is indeed the case with the patch applied.

For example:

test=# explain insert into primary_tbl select * from third_tbl
returning index, height;
                                    QUERY PLAN
-----------------------------------------------------------------------------------
 Gather  (cost=0.00..28.15 rows=9999 width=12)
   Workers Planned: 3
   ->  Parallel Insert on primary_tbl  (cost=0.00..28.15 rows=1040 width=12)
         ->  Parallel Seq Scan on third_tbl  (cost=0.00..87.25
rows=3225 width=12)
(4 rows)

test=# insert into primary_tbl select * from third_tbl returning index, height;
 index | height
-------+--------
     1 |    1.2
     2 |    1.2
     3 |    1.2
     4 |    1.2
     5 |    1.2
     6 |    1.2
     7 |    1.2

...

  9435 |    1.2
  9619 |    1.2
  9620 |    1.2
(9999 rows)

INSERT 0 9999


Regards,
Greg Nancarrow
Fujitsu Australia



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Prefer TG_TABLE_NAME over TG_RELNAME in tests
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Automatic HASH and LIST partition creation