RE: Parallel Inserts in CREATE TABLE AS - Mailing list pgsql-hackers

From houzj.fnst@fujitsu.com
Subject RE: Parallel Inserts in CREATE TABLE AS
Date
Msg-id OS0PR01MB57168C1BF60A55E1957193A894239@OS0PR01MB5716.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: Parallel Inserts in CREATE TABLE AS  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Parallel Inserts in CREATE TABLE AS  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
RE: Parallel Inserts in CREATE TABLE AS  ("tsunakawa.takay@fujitsu.com" <tsunakawa.takay@fujitsu.com>)
List 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 by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Parallel Inserts in CREATE TABLE AS
Next
From: "Andrey V. Lepikhov"
Date:
Subject: Re: Removing unneeded self joins