RE: Parallel Inserts in CREATE TABLE AS
От | tsunakawa.takay@fujitsu.com |
---|---|
Тема | RE: Parallel Inserts in CREATE TABLE AS |
Дата | |
Msg-id | TYAPR01MB2990E65FDCB3B2C942F2D684FE259@TYAPR01MB2990.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Parallel Inserts in CREATE TABLE AS ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Ответы |
Re: Parallel Inserts in CREATE TABLE AS
|
Список | pgsql-hackers |
From: houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> > + /* > + * We don't need to skip contacting FSM while inserting tuples > for > + * parallel mode, while extending the relations, workers > instead of > + * blocking on a page while another worker is inserting, can > check the > + * FSM for another page that can accommodate the tuples. > This results > + * in major benefit for parallel inserts. > + */ > + myState->ti_options = 0; > > I am not quite sure that disabling the " SKIP FSM " in parallel worker will bring > performance gain. > In my test environment, if I change this code to use option " > TABLE_INSERT_SKIP_FSM ", then there > seems no performance degradation. +1, probably. Does the code comment represent the situation like this? 1. Worker 1 is inserting into page 1. 2. Worker 2 tries to insert into page 1, but cannot acquire the buffer content lock of page 1 because worker 1 holds it. 3. Worker 2 looks up FSM to find a page with enough free space. But isn't FSM still empty during CTAS? Regards Takayuki Tsunakawa
В списке pgsql-hackers по дате отправления: