Re: Parallel Inserts in CREATE TABLE AS - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: Parallel Inserts in CREATE TABLE AS
Date
Msg-id CAFiTN-tzTfGc8VT3GrebRmziYZOiwsMzwwd7b+4G90LkUaGO3g@mail.gmail.com
Whole thread Raw
In response to Re: Parallel Inserts in CREATE TABLE AS  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses RE: Parallel Inserts in CREATE TABLE AS
Re: Parallel Inserts in CREATE TABLE AS
List pgsql-hackers
On Wed, Dec 16, 2020 at 12:06 PM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Tue, Dec 15, 2020 at 5:53 PM Bharath Rupireddy
> <bharath.rupireddyforpostgres@gmail.com> wrote:
> > I'm merging them to the original patch set and adding the test cases
> > to cover these cases. I will post the updated patch set soon.
>
> Attaching v12 patch set.
>
> 0001 - parallel inserts without tuple cost enforcement.
> 0002 - enforce planner for parallel tuple cost
> 0003 - test cases
>
> Please review it further.
>

I think it will be clean to implement the parallel CTAS when a
top-level node is the gather node.  Basically, the idea is that
whenever we get the gather on the top which doesn't have any
projection then we can push down the dest receiver directly to the
worker.  I agree that append is an exception that doesn't do any extra
processing other than appending the results, So IMHO it would be
better that in the first part we parallelize the plan where gather
node on top.  I see that we have already worked on the patch where the
append node is on top so I would suggest that we can keep that part in
a separate patch.

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Refactor routine to check for ASCII-only case
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: archive status ".ready" files may be created too early