On Tue, May 25, 2021 at 1:50 PM tsunakawa.ta...@fujitsu.com <tsunakawa.ta...@fujitsu.com> wrote: > > From: houzj.f...@fujitsu.com <houzj.f...@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.
I tried to explain it at [1]. Please have a look. > 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. I tried to explain it at [1]. Please have a look. > But isn't FSM still empty during CTAS? No, FSM will be built on the fly in case if we don't skip the FSM i.e. myState->ti_options = 0, see RelationGetBufferForTuple with use_fsm = true -> GetPageWithFreeSpace -> fsm_search -> fsm_set_and_search -> fsm_readbuf with extend = true. [1] https://www.postgresql.org/message-id/CALj2ACVdcrjwHXwvJqT-Fa32vnJEOjteep_3L24X8MK50E7M8w%40mail.gmail.com With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
