Re: POC: Lock updated tuples in tuple_update() and tuple_delete() - Mailing list pgsql-hackers

From Pavel Borisov
Subject Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Date
Msg-id CALT9ZEFas5Z7g+uxG=MppNRbpWCPNkiM10ZnCBkd+Fng3=LXuQ@mail.gmail.com
Whole thread Raw
In response to Re: POC: Lock updated tuples in tuple_update() and tuple_delete()  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: POC: Lock updated tuples in tuple_update() and tuple_delete()  (Alexander Korotkov <aekorotkov@gmail.com>)
List pgsql-hackers
Hi, Andres and Alexander!

On Tue, 7 Mar 2023, 10:10 Alexander Korotkov, <aekorotkov@gmail.com> wrote:
On Tue, Mar 7, 2023 at 4:50 AM Andres Freund <andres@anarazel.de> wrote:
> On 2023-03-02 14:28:56 +0400, Pavel Borisov wrote:
> > 2. Heap updates with low tuple concurrency:
> > Prepare with pkeys (pgbench -d postgres -i -I dtGvp -s 300 --unlogged-tables)
> > Update 3*10^7 rows, 50 conns (pgbench postgres -f
> > ./update-only-account.sql -s 300 -P10 -M prepared -T 600 -j 5 -c 50)
> >
> > Result: Both patches and master are the same within a tolerance of
> > less than 0.7%.
>
> What exactly does that mean? I would definitely not want to accept a 0.7%
> regression of the uncontended case to benefit the contended case here...

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!

Regards,
Pavel.

pgsql-hackers by date:

Previous
From: Dimitry Markman
Date:
Subject: Re: some problem explicit_bzero with building PostgreSQL on linux
Next
From: Sébastien Lardière
Date:
Subject: Re: Timeline ID hexadecimal format