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.