Horton

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

Alexander Korotkov <aekorotkov@gmail.com>

View thread View on postgr.es
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Pavel Borisov <pashkin.elfe@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-07T23:17:21Z
Lists: pgsql-hackers 
On Tue, Mar 7, 2023 at 7:26 PM Pavel Borisov <pashkin.elfe@gmail.com> wrote:
> On Tue, 7 Mar 2023, 10:10 Alexander Korotkov, <aekorotkov@gmail.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

Commits

  1. Add EvalPlanQual delete returning isolation test

  2. Allow locking updated tuples in tuple_update() and tuple_delete()

  3. Revert 764da7710b

  4. Revert 11470f544e

  5. Evade extra table_tuple_fetch_row_version() in ExecUpdate()/ExecDelete()

  6. Check that xmax didn't commit in freeze check.