MIME-Version: 1.0
References: 
 <CALj2ACVi9eTRYR=gdca5wxtj3Kk_9q9qVccxsS1hngTGOCjPwQ@mail.gmail.com>
 <20201217050522.GU30237@telsasoft.com>
 <CALj2ACVgT1iocd5nQ+rEmqt3xcCONkR037qbc8PiojdR39Ag=w@mail.gmail.com>
 <20201217204442.GX30237@telsasoft.com>
 <CALj2ACW3BC5kgdffZ2LD_CT2wQoXVc29kGB74SVWnGZ=UFqcAQ@mail.gmail.com>
 <20201218175439.GA30237@telsasoft.com> <20201221074725.GF30237@telsasoft.com>
 <CALj2ACWMnZZCu=G0PJkEeYYicKeuJ-X=SU19i6vQ1+=uXz8u0Q@mail.gmail.com>
 <20201225023958.GW30237@telsasoft.com>
 <CALj2ACVDtYYRYD2SC+X2ALOUkhnUcgC7RLxiEYVWW2HxxrfRww@mail.gmail.com>
 <96eaa813-4ad6-e80a-04a4-cc8082d356dd@swarm64.com>
 <CALj2ACVsiAZMsP8p5MPg6SSEtoMFFaiAa6j2AFtEQJDhfbgs3Q@mail.gmail.com>
 <508af801-6356-d36b-1867-011ac6df8f55@swarm64.com>
 <CALj2ACUmL3+xLFtVbdcNpo_=ubdi=_nsp6MNq__xWwL=NGkdgA@mail.gmail.com>
 <CALj2ACXoKTQuz8FKJxgB_=Jr_2_ZCy7gDteBrUa_5pd7Ov_1Tg@mail.gmail.com>
 <CALj2ACVbcYCvTw_jMnuGjLMBiQug7YAL3ezJFM9QMdewoJZLcw@mail.gmail.com>
 <CAFiTN-tBRvtRNgeW5mmdwXoDNubhUrYqzLF58O_+JLo_cFb_7Q@mail.gmail.com>
In-Reply-To: 
 <CAFiTN-tBRvtRNgeW5mmdwXoDNubhUrYqzLF58O_+JLo_cFb_7Q@mail.gmail.com>
From: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Date: Tue, 9 Mar 2021 13:45:18 +0530
Message-ID: 
 <CALj2ACWZ95GhLTXc0dw1_Nu05xs130HPCnWX4tfkmp0CtBCMJg@mail.gmail.com>
Subject: Re: New Table Access Methods for Multi and Single Inserts
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Luc Vlaming <luc@swarm64.com>, Justin Pryzby <pryzby@telsasoft.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
 Andres Freund <andres@anarazel.de>,
	Paul Guo <guopa@vmware.com>, Jeff Davis <pgsql@j-davis.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CALj2ACWZ95GhLTXc0dw1_Nu05xs130HPCnWX4tfkmp0CtBCMJg%40mail.gmail.com>
Precedence: bulk

On Mon, Mar 8, 2021 at 6:37 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Sat, Feb 20, 2021 at 11:15 AM Bharath Rupireddy
> <bharath.rupireddyforpostgres@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