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

From tsunakawa.takay@fujitsu.com
Subject RE: Parallel Inserts in CREATE TABLE AS
Date
Msg-id TYAPR01MB29908225875CA289F42FE388FE239@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel Inserts in CREATE TABLE AS  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
> I think we can discuss this in a separate thread and see what other
> hackers think.

OK, unless we won't get stuck in the current direction.  (Our goal is to not degrade in performance, but to outperform
serialexecution, isn't it?)
 


> If the idea is to give the user control of whether or not to use the
> separate RING BUFFER for bulk inserts/writes, then how about giving it
> as a rel option? Currently BAS_BULKWRITE (GetBulkInsertState), is
> being used by CTAS, Refresh Mat View, Table Rewrites (ATRewriteTable)
> and COPY. Furthermore, we could make the rel option an integer and
> allow users to provide the size of the ring buffer they want to choose
> for a particular bulk insert operation (of course with a max limit
> which is not exceeding the shared buffers or some reasonable amount
> not exceeding the RAM of the system).

I think it's not a table property but an execution property.  So, it'd be appropriate to control it with the SET
command,just like the DBA sets work_mem and maintenance_work_mem for specific maintenance operations.
 

I'll stop on this here...


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS
Next
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side