On Mon, Mar 8, 2021 at 6:37 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Sat, Feb 20, 2021 at 11:15 AM Bharath Rupireddy > <bharath.rupireddyforpostg...@gmail.com> wrote: > > > > Please review the v3 patch set further. > > > > Below is the performance gain measured for CREATE TABLE AS with the > > new multi insert am propsed in this thread: > > > > case 1 - 2 integer(of 4 bytes each) columns, 3 varchar(8), tuple size > > 59 bytes, 100mn tuples > > on master - 185sec > > on master with multi inserts - 121sec, gain - 1.52X > > > > case 2 - 2 bigint(of 8 bytes each) columns, 3 name(of 64 bytes each) > > columns, 1 varchar(8), tuple size 241 bytes, 100mn tuples > > on master - 367sec > > on master with multi inserts - 291sec, gain - 1.26X > > > > case 3 - 2 integer(of 4 bytes each) columns, tuple size 32 bytes, 100mn > > tuples > > on master - 130sec > > on master with multi inserts - 105sec, gain - 1.23X > > > > case 4 - 2 bigint(of 8 bytes each) columns, 16 name(of 64 bytes each) > > columns, tuple size 1064 bytes, 10mn tuples > > on master - 120sec > > on master with multi inserts - 115sec, gain - 1.04X > > Performance numbers look good, especially with the smaller tuple size.
Thanks. > I was looking into the patch and I have a question. > > +static inline void > +table_insert_v2(TableInsertState *state, TupleTableSlot *slot) > +{ > + state->rel->rd_tableam->tuple_insert_v2(state, slot); > +} > + > +static inline void > +table_multi_insert_v2(TableInsertState *state, TupleTableSlot *slot) > +{ > + state->rel->rd_tableam->multi_insert_v2(state, slot); > +} > > Why do we need to invent a new version table_insert_v2? And also why > it is named table_insert* instead of table_tuple_insert*? New version, because we changed the input parameters, now passing the params via TableInsertState but existing table_tuple_insert doesn't do that. If okay, I can change table_insert_v2 to table_tuple_insert_v2? Thoughts? With Regards, Bharath Rupireddy. EnterpriseDB: http://www.enterprisedb.com