Re: Parallel Inserts in CREATE TABLE AS
От | Bharath Rupireddy |
---|---|
Тема | Re: Parallel Inserts in CREATE TABLE AS |
Дата | |
Msg-id | CALj2ACUT+AyFgo_ga8uyvsd-OJOm9QH2yZ7R2_0nsnHG2e78Wg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Parallel Inserts in CREATE TABLE AS (Dilip Kumar <dilipbalaut@gmail.com>) |
Ответы |
Re: Parallel Inserts in CREATE TABLE AS
Re: Parallel Inserts in CREATE TABLE AS |
Список | pgsql-hackers |
On Wed, Dec 30, 2020 at 10:32 AM Dilip Kumar <dilipbalaut@gmail.com> wrote: > I have completed reviewing 0001, I don't have more comments, just one > question. Soon I will review the remaining patches. Thanks. > + /* If parallel inserts are to be allowed, set a few extra information. */ > + if (myState->is_parallel) > + { > + myState->object_id = intoRelationAddr.objectId; > + > + /* > + * 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; > > Is there any performance data for this or just theoretical analysis? I have seen that we don't get much performance with the skip fsm option, though I don't have the data to back it up. I'm planning to run performance tests after the patches 0001, 0002 and 0003 get reviewed. I will capture the data at that time. Hope that's fine. With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: