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.sokolov@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;

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