> > 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
