Re: [RFC] Lock-free XLog Reservation from WAL
От | Yura Sokolov |
---|---|
Тема | Re: [RFC] Lock-free XLog Reservation from WAL |
Дата | |
Msg-id | f7a71ee8-d554-4c08-82f4-ed3d28931ce5@postgrespro.ru обсуждение исходный текст |
Ответ на | Re: [RFC] Lock-free XLog Reservation from WAL (Japin Li <japinli@hotmail.com>) |
Список | pgsql-hackers |
22.01.2025 10:54, Japin Li wrote: > 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. Oh, I see: I forgot that I removed increase of NUM_XLOGINSERT_LOCKS from v2 patch.
В списке pgsql-hackers по дате отправления: