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-vRLMZTOPvEvXo=s0Omti4hGG6Vozvuw2dKLvB3gDojZw@mail.gmail.com
Whole thread Raw
In response to RE: Parallel Inserts in CREATE TABLE AS  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
Responses RE: Parallel Inserts in CREATE TABLE AS  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List pgsql-hackers
On Thu, 27 May 2021 at 11:32 AM, tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com> wrote:
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 remove this 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.

Basically you are creating a new table and loading data to it and that means you will be less likely to access those data soon so for such thing spoiling buffer cache may not be a good idea.   I was just suggesting only for experiments for identifying the root cause.

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

pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Race condition in recovery?
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: Parallel Inserts in CREATE TABLE AS