RE: Use simplehash.h instead of dynahash in SMgr
От | Jakub Wartak |
---|---|
Тема | RE: Use simplehash.h instead of dynahash in SMgr |
Дата | |
Msg-id | VI1PR0701MB6960E6D31B180379D24D57BFF6599@VI1PR0701MB6960.eurprd07.prod.outlook.com обсуждение исходный текст |
Ответ на | Re: Use simplehash.h instead of dynahash in SMgr (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Use simplehash.h instead of dynahash in SMgr
|
Список | pgsql-hackers |
Hi David, Alvaro, -hackers > Hi David, > > You're probably aware of this, but just to make it explicit: Jakub Wartak was > testing performance of recovery, and one of the bottlenecks he found in > some of his cases was dynahash as used by SMgr. It seems quite possible > that this work would benefit some of his test workloads. I might be a little bit out of the loop, but as Alvaro stated - Thomas did plenty of excellent job related to recovery performancein that thread. In my humble opinion and if I'm not mistaken (I'm speculating here) it might be *not* how Smgrhash works, but how often it is being exercised and that would also explain relatively lower than expected(?) gains here.There are at least two very important emails from him that I'm aware that are touching the topic of reordering/compacting/batchingcalls to Smgr: https://www.postgresql.org/message-id/CA%2BhUKG%2B2Vw3UAVNJSfz5_zhRcHUWEBDrpB7pyQ85Yroep0AKbw%40mail.gmail.com https://www.postgresql.org/message-id/flat/CA%2BhUKGK4StQ%3DeXGZ-5hTdYCmSfJ37yzLp9yW9U5uH6526H%2BUeg%40mail.gmail.com Another potential option that we've discussed is that the redo generation itself is likely a brake of efficient recoveryperformance today (e.g. INSERT-SELECT on table with indexes, generates interleaved WAL records that touch often limitedset of blocks that usually put Smgr into spotlight). -Jakub Wartak.
В списке pgsql-hackers по дате отправления: