RE: Parallel Inserts in CREATE TABLE AS
От | houzj.fnst@fujitsu.com |
---|---|
Тема | RE: Parallel Inserts in CREATE TABLE AS |
Дата | |
Msg-id | OS0PR01MB57168C1BF60A55E1957193A894239@OS0PR01MB5716.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Parallel Inserts in CREATE TABLE AS (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Parallel Inserts in CREATE TABLE AS
RE: Parallel Inserts in CREATE TABLE AS |
Список | pgsql-hackers |
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Sent: Thursday, May 27, 2021 12:46 PM > On Thu, May 27, 2021 at 7:12 AM houzj.fnst@fujitsu.com > <houzj.fnst@fujitsu.com> wrote: > > I am afraid that the using the FSM seems not get a stable performance > > gain(at least on my machine), I will take a deep look into this to > > figure out the difference. A naive idea it that the benefit that bulk extension > bring is not much greater than the cost in FSM. > > Do you have some ideas on it ? > > I think, if we try what Amit and I said in [1], we should get some insights on > whether the bulk relation extension is taking more time or the FSM lookup. I > plan to share the testing patch adding the timings and the counters so that you > can also test from your end. I hope that's fine with you. Sure, it will be nice if we can calculate the exact time. Thanks in advance. BTW, I checked my test results, I was testing INSERT INTO unlogged table. I re-test INSERT into normal(logged) table again, it seems [SKIP FSM] still Looks slightly better. Although, the 4 workers case still has performance degradation compared to serial case. SERIAL: 58759.213 ms PARALLEL 2 WORKER [NOT SKIP FSM]: 68390.221 ms [SKIP FSM]: 58633.924 ms PARALLEL 4 WORKER [NOT SKIP FSM]: 67448.142 ms [SKIP FSM]: 66,960.305 ms Best regards, houzj
В списке pgsql-hackers по дате отправления: