From: | "houzj(dot)fnst(at)fujitsu(dot)com" <houzj(dot)fnst(at)fujitsu(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
Cc: | "tanghy(dot)fnst(at)fujitsu(dot)com" <tanghy(dot)fnst(at)fujitsu(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Zhihong Yu <zyu(at)yugabyte(dot)com>, Luc Vlaming <luc(at)swarm64(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com> |
Subject: | RE: Parallel Inserts in CREATE TABLE AS |
Date: | 2021-03-19 10:10:24 |
Message-ID: | OS0PR01MB57164C2677384071A7F3F25094689@OS0PR01MB5716.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > They are pretty simple though. I think someone can also check if the
> > same regression exists for parallel inserts in "INSERT INTO SELECT"
> > patch set as well for larger tuple sizes.
>
> Thanks for reminding.
> I did some performance tests for parallel inserts in " INSERT INTO SELECT " with
> the testcase you provided, the regression seems does not exists in "INSERT
> INTO SELECT".
I forgot to share the test results with Parallel CTAS.
I test with sql: explain analyze verbose create table test as select * from tenk1;
> CREATE UNLOGGED TABLE tenk1(c1 int, c2 int);
> CREATE UNLOGGED TABLE tenk1(c1 int, c2 int, c3 varchar(8), c4 varchar(8), c5 varchar(8));
> CREATE UNLOGGED TABLE tenk1(c1 bigint, c2 bigint, c3 name, c4 name, c5 name, c6 varchar(8));
I did not see regression in these cases (low tuple size).
> CREATE UNLOGGED TABLE tenk1(c1 bigint, c2 bigint, c3 name, c4 name, c5 name, c6 name, c7 name, c8 name, c9 name, c10 name, c11 name, c12 name, c13 name, c14 name,
> c15 name, c16 name, c17 name, c18 name);
I can see the degradation in this case.
The average test results of CTAS are:
Serial CTAS -----Execution Time: 80892.240 ms
Parallel CTAS -----Execution Time: 85725.591 ms
About 6% degradation.
I also test with Parallel INSERT patch in this case.
(Note: to keep consistent, I create a new target table(test) before inserting.)
The average test results of Parallel INSERT are:
Serial Parallel INSERT ------ Execution Time: 90075.501 ms
Parallel Parallel INSERT----- Execution Time: 85812.202 ms
No degradation.
Best regards,
houzj
From | Date | Subject | |
---|---|---|---|
Next Message | wangsh.fnst@fujitsu.com | 2021-03-19 10:11:46 | RE: invalid data in file backup_label problem on windows |
Previous Message | Fujii Masao | 2021-03-19 09:27:10 | Re: Wrong statistics for size of XLOG_SWITCH during pg_waldump. |