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

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; I will try 128
and update the result later.

--
Regrads,
Japin Li