> 23 дек. 2020 г., в 21:31, Gilles Darold <gilles@darold.net> написал(а):
>
> Sorry for the response delay, we have run several others tests trying to figure out the performances gain per patch
butunfortunately we have very heratic results. With the same parameters and patches the test doesn't returns the same
resultsfollowing the day or the hour of the day. This is very frustrating and I suppose that this is related to the
Azurearchitecture. The only thing that I am sure is that we had the best performances results with all patches and
>
> multixact_offsets_slru_buffers = 256
> multixact_members_slru_buffers = 512
> multixact_local_cache_entries = 4096
>
>
> but I can not say if all or part of the patches are improving the performances. My feeling is that performances gain
relatedto patches 1 (shared lock) and 3 (conditional variable) do not have much to do with the performances gain
comparedto just tuning the multixact buffers. This is when the multixact contention is observed but perhaps they are
delayingthe contention. It's all the more frustrating that we had a test case to reproduce the contention but not the
architectureapparently.
Hi! Thanks for the input.
I think we have a consensus here that configuring SLRU size is beneficial for MultiXacts.
There is proposal in nearby thread [0] on changing default value of commit_ts SLRU buffers.
In my experience from time to time there can be problems with subtransactions cured by extending subtrans SLRU.
Let's make all SLRUs configurable?
PFA patch with draft of these changes.
Best regards, Andrey Borodin.
[0] https://www.postgresql.org/message-id/flat/20210115220744.GA24457%40alvherre.pgsql