Re: POC: Lock updated tuples in tuple_update() and tuple_delete()

From: Alexander Korotkov <aekorotkov(at)gmail(dot)com>
To: Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Mason Sharp <masonlists(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Subject: Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Date: 2023-03-07 23:17:21
Message-ID: CAPpHfdtNALW_8hxadEz6-_tQCZr2nFNgewvMa++-h8kssMLWZA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 7, 2023 at 7:26 PM Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com> wrote:
> On Tue, 7 Mar 2023, 10:10 Alexander Korotkov, <aekorotkov(at)gmail(dot)com> wrote:
>> I don't know what exactly Pavel meant, but average overall numbers for
>> low concurrency are.
>> master: 420401 (stddev of average 233)
>> patchset v11: 420111 (stddev of average 199)
>> The difference is less than 0.1% and that is very safely within the error.
>
>
> Yes, the only thing that I meant is that for low-concurrency case the results between patch and master are within the difference between repeated series of measurements. So I concluded that the test can not prove any difference between patch and master.
>
> I haven't meant or written there is some performance degradation.
>
> Alexander, I suppose did an extra step and calculated overall average and stddev, from raw data provided. Thanks!

Pavel, thank you for verifying this.

Could you, please, rerun performance benchmarks for the v13? It
introduces LazyTupleTableSlot, which shouldn't do any measurable
impact on performance. But still.

------
Regards,
Alexander Korotkov

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-03-08 00:25:02 optimize several list functions with SIMD intrinsics
Previous Message Peter Smith 2023-03-07 22:37:10 Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher