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