Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Alexander Korotkov <aekorotkov@gmail.com>, Aleksander Alekseev <aleksander@timescale.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Mason Sharp <masonlists@gmail.com>, vignesh C <vignesh21@gmail.com>
Date: 2023-03-07T01:50:29Z
Lists: pgsql-hackers 
Hi,

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...

Greetings,

Andres Freund

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.