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 TYAPR01MB29904A919B92D8CF873A78F9FE239@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel Inserts in CREATE TABLE AS  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Parallel Inserts in CREATE TABLE AS  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
From: Dilip Kumar <dilipbalaut@gmail.com>
> I think some other cause of contention on relation extension locks are
> 1. CTAS is using a buffer strategy and due to that, it might need to
> evict out the buffer frequently for getting the new block in.  Maybe
> we can identify by turning off the buffer strategy for CTAS and
> increasing the shared buffer so that data fits in memory.

Yes, both Bhrath-san (on a rich-man's machine) and I (on a poor-man's VM) saw that it's effective.  I think we should
removethis shackle from CTAS.
 

The question is why CTAS chose to use BULKWRITE strategy in the past.  We need to know that to make a better decision.
Ican understand why VACUUM uses a ring buffer, because it should want to act humbly as a background maintenance task to
notcause trouble to frontend tasks.  But why does CTAS have to be humble?  If CTAS needs to be modest, why doesn't it
usethe BULKREAD strategy for its SELECT?
 


Regards
Takayuki Tsunakawa


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Incorrect GUC descriptions in docs and postgresql.conf.sample
Next
From: Dilip Kumar
Date:
Subject: Re: Race condition in recovery?