From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | Luc Vlaming <luc(at)swarm64(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Paul Guo <guopa(at)vmware(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com> |
Subject: | Re: New Table Access Methods for Multi and Single Inserts |
Date: | 2021-03-09 08:15:18 |
Message-ID: | CALj2ACWZ95GhLTXc0dw1_Nu05xs130HPCnWX4tfkmp0CtBCMJg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 8, 2021 at 6:37 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
>
> On Sat, Feb 20, 2021 at 11:15 AM Bharath Rupireddy
> <bharath(dot)rupireddyforpostgres(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2021-03-09 08:20:53 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Kyotaro Horiguchi | 2021-03-09 08:11:07 | Re: shared-memory based stats collector |