| From: | "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com> |
|---|---|
| To: | 'Dilip Kumar' <dilipbalaut(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com>, "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Luc Vlaming <luc(at)swarm64(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Subject: | RE: Parallel Inserts in CREATE TABLE AS |
| Date: | 2021-05-27 06:02:33 |
| Message-ID: | TYAPR01MB29904A919B92D8CF873A78F9FE239@TYAPR01MB2990.jpnprd01.prod.outlook.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
From: Dilip Kumar <dilipbalaut(at)gmail(dot)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. I can understand why VACUUM uses a ring buffer, because it should want to act humbly as a background maintenance task to not cause trouble to frontend tasks. But why does CTAS have to be humble? If CTAS needs to be modest, why doesn't it use the BULKREAD strategy for its SELECT?
Regards
Takayuki Tsunakawa
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dilip Kumar | 2021-05-27 06:14:47 | Re: Race condition in recovery? |
| Previous Message | Michael Paquier | 2021-05-27 05:59:55 | Re: Incorrect GUC descriptions in docs and postgresql.conf.sample |