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

On Wed, 22 Jan 2025 at 11:22, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
> 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 apply the following two patches:

1. Lock-free XLog Reservation using lock-free hash-table
2. Increase NUM_XLOGINSERT_LOCKS to 64

I noticed the patch from the [1]. However, I haven't tested it independently.

--
Regrads,
Japin Li