From: | Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | "Zhou, Zhiguo" <zhiguo(dot)zhou(at)intel(dot)com>, wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [RFC] Lock-free XLog Reservation from WAL |
Date: | 2025-01-23 12:03:04 |
Message-ID: | a232c74d-78b1-4751-a3bb-28817b6932d7@postgrespro.ru |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
23.01.2025 11:46, Japin Li пишет:
> On Wed, 22 Jan 2025 at 22:44, Japin Li <japinli(at)hotmail(dot)com> wrote:
>> On Wed, 22 Jan 2025 at 17:02, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru> wrote:
>>> I believe, I know why it happens: I was in hurry making v2 by
>>> cherry-picking internal version. I reverted some changes in
>>> CalcCuckooPositions manually and forgot to add modulo
>>> PREV_LINKS_HASH_CAPA.
>>>
>>> Here's the fix:
>>>
>>> pos->pos[0] = hash % PREV_LINKS_HASH_CAPA;
>>> - pos->pos[1] = pos->pos[0] + 1;
>>> + pos->pos[1] = (pos->pos[0] + 1) % PREV_LINKS_HASH_CAPA;
>>> pos->pos[2] = (hash >> 16) % PREV_LINKS_HASH_CAPA;
>>> - pos->pos[3] = pos->pos[2] + 2;
>>> + pos->pos[3] = (pos->pos[2] + 2) % PREV_LINKS_HASH_CAPA;
>>>
>>> Any way, here's v3:
>>> - excess file "v0-0001-Increase..." removed. I believe it was source
>>> of white-space apply warnings.
>>> - this mistake fixed
>>> - more clear slots strategies + "8 positions in two cache-lines" strategy.
>>>
>>> You may play with switching PREV_LINKS_HASH_STRATEGY to 2 or 3 and see
>>> if it affects measurably.
>>
>> Thanks for your quick fixing. I will retest it tomorrow.
>
> Hi, Yura Sokolov
>
> Here is my test result of the v3 patch:
>
> | case | min | avg | max |
> |-------------------------------+------------+------------+------------|
> | master (44b61efb79) | 865,743.55 | 871,237.40 | 874,492.59 |
> | v3 | 857,020.58 | 860,180.11 | 864,355.00 |
> | v3 PREV_LINKS_HASH_STRATEGY=2 | 853,187.41 | 855,796.36 | 858,436.44 |
> | v3 PREV_LINKS_HASH_STRATEGY=3 | 863,131.97 | 864,272.91 | 865,396.42 |
>
> It seems there are some performance decreases :( or something I missed?
>
Hi, Japin.
(Excuse me for duplicating message, I found I sent it only to you first
time).
v3 (as well as v2) doesn't increase NUM_XLOGINSERT_LOCKS itself.
With only 8 in-progress inserters spin-lock is certainly better than any
more complex solution.
You need to compare "master" vs "master + NUM_XLOGINSERT_LOCKS=64" vs
"master + NUM_XLOGINSERT_LOCKS=64 + v3".
And even this way I don't claim "Lock-free reservation" gives any profit.
That is why your benchmarking is very valuable! It could answer, does we
need such not-small patch, or there is no real problem at all?
----
regards
Yura Sokolov aka funny-falcon
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-01-23 12:11:31 | Re: pgsql: Doc: Update the interaction of tablesync with wal_retrieve_retry |
Previous Message | Shlok Kyal | 2025-01-23 11:52:18 | Re: Virtual generated columns |