Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Pavel Borisov <pashkin.elfe@gmail.com>
From: Pavel Borisov <pashkin.elfe@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>,
Mason Sharp <masonlists@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-03-07T16:26:19Z
Lists: 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. >
Commits
-
Add EvalPlanQual delete returning isolation test
- 8ffc2aa720a2 17.0 landed
-
Allow locking updated tuples in tuple_update() and tuple_delete()
- 87985cc92522 17.0 landed
- 11470f544e37 16.0 landed
-
Revert 764da7710b
- b0b91ced167f 16.0 landed
-
Revert 11470f544e
- 2b65bf046d8a 16.0 landed
-
Evade extra table_tuple_fetch_row_version() in ExecUpdate()/ExecDelete()
- 764da7710bf6 16.0 landed
-
Check that xmax didn't commit in freeze check.
- eb5ad4ff05fd 16.0 cited