> 21 янв. 2022 г., в 05:19, Shawn Debnath <sdn@amazon.com> написал(а):
>
> On Thu, Jan 20, 2022 at 09:21:24PM +0500, Andrey Borodin wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you
canconfirm the sender and know the content is safe.
>>
>>> 20 янв. 2022 г., в 20:44, Shawn Debnath <sdn@amazon.com> написал(а):
>> Can you please also test 2nd patch against a large multixact SLRUs?
>> 2nd patch is not intended to do make thing better on default buffer sizes. It must save the perfromance in case of
reallyhuge SLRU buffers.
>
> Test was performed on 128/256 for multixact offset/members cache as
> stated in my previous email. Sure I can test it for higher values - but
> what's a real world value that would make sense? We have been using this
> configuration successfully for a few of our customers that ran into
> MultiXact contention.
Sorry, seems like I misinterpreted results yesterday.
I had one concern about 1st patch step: it makes CLOG buffers size dependent on shared_buffers. But in your tests you
seemto have already exercised xact_buffers = 24576 without noticeable degradation. Is it correct? I doubt a little bit
thatlinear search among 24K elements on each CLOG access does not incur performance impact, but your tests seem to
proveit.
IMV splitting SLRU buffer into banks would make sense for values greater than 1<<10. But you are right that 256 seems
enoughto cope with most of problems of multixacts so far. I just thought about stressing SLRU buffers with multixacts
tobe sure that CLOG buffers will not suffer degradation. But yes, it's too indirect test.
Maybe, just to be sure, let's repeat tests with autovacuum turned off to stress xact_buffers?
Thanks!
Best regards, Andrey Borodin.