On Fri, 29 Jul 2022 at 18:24, Michail Nikolaev
<michail.nikolaev@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/