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

Hi, Pavel!

On Fri, Jul 29, 2022 at 11:12 AM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> I ran the following benchmark on master branch (15) vs patch (15-lock):
>
> On the 36-vcore AWS server, I've run an UPDATE-only pgbench script with 50 connections on pgbench_tellers with 100 rows. The idea was to introduce as much as possible concurrency for updates but avoid much clients being in a wait state.
> Indexes were not built to avoid index-update-related delays.
> Done 2 runs each consisting of 6 series of updates (1st run: master-patch-master-patch-master-patch, 2nd run patch-master-patch-master-patch-master)
> Each series started a fresh server and did VACUUM FULL to avoid bloating heap relation after the previous series to affect the current. It collected data for 10 minutes with first-minute data being dropped.
> Disk-related operations were suppressed where possible (WAL, fsync etc.)
>
> postgresql.conf:
> fsync = off
> autovacuum = off
> full_page_writes = off
> max_worker_processes = 99
> max_parallel_workers = 99
> max_connections = 100
> shared_buffers = 4096MB
> work_mem = 50MB
>
> Attached are pictures of 2 runs, shell script, and SQL script that were running.
> According to htop all 36-cores were loaded to ~94% in each series
>
> I'm not sure how to interpret the results. Seems like a TPS difference between runs is significant, with average performance with lock-patch (15lock) seeming a little bit faster than the master (15).
>
> Could someone try to repeat this on another server? What do you think?

Thank you for your benchmarks.  The TPS variation is high, and run
order heavily affects the result.  Nevertheless, I think there is a
small but noticeable positive effect of the patch.  I'll continue
working on the patch bringing it into more acceptable shape.

------
Regards,
Alexander Korotkov