Re: [RFC] Lock-free XLog Reservation from WAL

22.01.2025 10:54, Japin Li пишет:
> On Wed, 22 Jan 2025 at 10:25, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)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;

Ok, that is good.
Did you just increased number of locks, or applied
"several-attempts-to-lock"
from [1] as well? It will be interesting how it affects performance in this
case. And it is orthogonal to "lock-free reservation", so they could
applied simultaneously.

> I will try 128 and update the result later.

Thank you.

[1]
https://www.postgresql.org/message-id/3b11fdc2-9793-403d-b3d4-67ff9a00d447%40postgrespro.ru

------
regards
Yura