22.01.2025 10:54, Japin Li wrote:
On Wed, 22 Jan 2025 at 10:25, Yura Sokolov <y.soko...@postgrespro.ru> wrote:
22.01.2025 09:09, Japin Li пишет:
Hi, Yura Sokolov
Thanks for updating the patch.
I test the v2 patch using BenchmarkSQL 1000 warehouse, and here is the tpmC
result:
case | min | avg | max
--------------------+------------+------------+--------------
master (patched) | 988,461.89 | 994,916.50 | 1,000,362.40
master (44b61efb79) | 857,028.07 | 863,174.59 | 873,856.92
The patch provides a significant improvement.
I just looked through the patch, here are some comments.
1.
The v2 patch can't be applied cleanly.
Applying: Lock-free XLog Reservation using lock-free hash-table
.git/rebase-apply/patch:33: trailing whitespace.
.git/rebase-apply/patch:37: space before tab in indent.
{
.git/rebase-apply/patch:38: space before tab in indent.
int i;
.git/rebase-apply/patch:39: trailing whitespace.
.git/rebase-apply/patch:46: space before tab in indent.
LWLockReleaseClearVar(&WALInsertLocks[i].l.lock,
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.
2.
And there is a typo:
+ * PrevLinksHash is a lock-free hash table based on Cuckoo
algorith. It is
+ * mostly 4 way: for every element computed two positions h1, h2, and
s/algorith/algorithm/g
Hi, Japin
Thank you a lot for measuring and comments.
May I ask you to compare not only against master, but against straight
increase of NUM_XLOGINSERT_LOCKS to 128 as well?
This way the profit from added complexity will be more obvious: does
it pay for self or not.
The above test already increases NUM_XLOGINSERT_LOCKS to 64; I will try 128
and update the result later.
Oh, I see: I forgot that I removed increase of NUM_XLOGINSERT_LOCKS from
v2 patch.
