Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Alexander Korotkov <aekorotkov@gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Chris Travers <chris.travers@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2023-03-20T22:25:11Z
Lists: pgsql-hackers
Attachments
- 0001-Evade-extra-table_tuple_fetch_row_version-in-Exe-v15.patch (application/octet-stream) patch v15-0001
- 0002-Allow-locking-updated-tuples-in-tuple_update-and-v15.patch (application/octet-stream) patch v15-0002
- low_concurrency.tar.gz (application/x-gzip)
- high_concurrency.tar.gz (application/x-gzip)
Hi! On Sun, Mar 12, 2023 at 7:05 PM Alexander Korotkov <aekorotkov@gmail.com> wrote: > The revised patch set is attached. Some comments are improved. Also, > we implicitly skip the new facility for the MERGE case. As I get Dean > Rasheed is going to revise the locking for MERGE soon [1]. > > Pavel, could you please re-run your test case on the revised patch? I found the experiments made by Pavel [1] hard to reproduce due to the high variation of the TPS. Instead, I constructed a different benchmark, which includes multiple updates (40 rows) in one query, and run it on c5d.18xlarge. That produces stable performance results as well as measurable performance benefits of the patch. I found that patchsets v11 and v14 not showing any performance improvements over v10. v10 is also much less invasive for heap-related code. This is why I made v15 using the v10 approach and porting LazyTupleTableSlot and improved comments there. I think this should address some of Andres's complaints regarding introducing too much infrastructure [2]. The average results for high concurrency case (errors are given for a 95% confidence level) are given below. We can see that v15 gives a measurable performance improvement. master = 40084 +- 447 tps patchset v10 = 41761 +- 1117 tps patchset v11 = 41473 +- 773 tps patchset v14 = 40966 +- 1008 tps patchset v15 = 42855 +- 977 tps The average results for low concurrency case (errors are given for a 95% confidence level) are given below. It verifies that the patch introduces no overhead in the low concurrency case. master = 50626 +- 784 tps patchset v15 = 51297 +- 876 tps See attachments for raw experiment data and scripts. So, as we can see patch gives a small performance improvement for the heap in edge high concurrency case. But also it improves table AM API for future use cases [3][4]. I'm going to push patchset v15 if no objections. Links 1. https://www.postgresql.org/message-id/CALT9ZEHKdCF_jCoK2ErUuUtCuYPf82%2BZr1XE5URzneSFxz3zqA%40mail.gmail.com 2. https://www.postgresql.org/message-id/20230308012157.wo73y22ll2cojpvk%40awork3.anarazel.de 3. https://www.postgresql.org/message-id/CAPpHfdu1dqqcTz9V9iG-ZRewYAFL2VhizwfiN5SW%3DZ%2B1rj99-g%40mail.gmail.com 4. https://www.postgresql.org/message-id/167846860062.628976.2440696515718158538.pgcf%40coridan.postgresql.org ------ Regards, Alexander Korotkov
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