Hi, On 2021-10-14 17:28:34 +0900, Kyotaro Horiguchi wrote: > At Wed, 13 Oct 2021 19:52:52 +0900 (JST), Kyotaro Horiguchi > <horikyota....@gmail.com> wrote in > > Although needing a bit of care for the difference of invalid values > > for both though, BackendId can be easily replaced with pgprocno almost > > mechanically except sinvaladt. Therefore, we can confine the current > > backend ID within sinvaladt isolating from other part. The ids > > dedicated for sinvaladt can be packed to small range and perfomance > > won't be damaged.
FWIW, I don't actually think there's necessarily that strong a need for density in sinvaladt. With a few relatively changes we can get rid of the O(n) work in the most crucial paths. In https://www.postgresql.org/message-id/20210802171255.k4yv5cfqaqbuuy6f%40alap3.anarazel.de I wrote: > Another approach to deal with this could be to simply not do the O(n) work in > SIInsertDataEntries(). It's not obvious that ->hasMessages is actually > necessary - we could atomically read maxMsgNum without acquiring a lock > instead of needing the per-backend ->hasMessages. I don't the density would > be a relevant factor in SICleanupQueue(). This'd get rid of the need of density *and* make SIInsertDataEntries() cheaper. Greetings, Andres Freund
