On Fri, 29 Jul 2022 at 18:24, Michail Nikolaev <michail.nikol...@gmail.com> wrote:
> > A simple patch like this seems to hit the main concern, aiming to keep > > the array from spreading out and impacting snapshot performance for > > SELECTs, yet not doing it so often that the startup process has a > > higher burden of work. > > Nice, I'll do performance testing for both versions and master branch > as baseline. The objective of all patches is to touch the smallest number of cachelines when accessing the KnownAssignedXacts array. The trade-off is to keep the array small with the minimum number of compressions, so that normal snapshots don't feel the contention and so that the Startup process doesn't slow down because of the extra compression work. The values I've chosen in the recent patch are just guesses at what we'll need to reduce it to, so there may be some benefit in varying those numbers to see the effects. It did also occur to me that we might need a separate process to perform the compressions, which we might be able to give to WALWriter. -- Simon Riggs http://www.EnterpriseDB.com/
