Re: MultiXact\SLRU buffers configuration

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MultiXact\SLRU buffers configuration
Date: 2020-08-28 18:08:34
Message-ID: a7f1c4e1-1015-92a4-2bd4-6736bd13d03e@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 08.07.2020 10:03, Andrey M. Borodin wrote:
>
>> 2 июля 2020 г., в 17:02, Daniel Gustafsson <daniel(at)yesql(dot)se> написал(а):
>>
>>> On 15 May 2020, at 02:03, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> wrote:
>>> Generally in such cases, condition variables would work. In the
>>> attached PoC, the reader side gets no penalty in the "likely" code
>>> path. The writer side always calls ConditionVariableBroadcast but the
>>> waiter list is empty in almost all cases. But I couldn't cause the
>>> situation where the sleep 1000u is reached.
>> The submitted patch no longer applies, can you please submit an updated
>> version? I'm marking the patch Waiting on Author in the meantime.
> Thanks, Daniel! PFA V2
>
> Best regards, Andrey Borodin.

1) The first patch is sensible and harmless, so I think it is ready for
committer. I haven't tested the performance impact, though.

2) I like the initial proposal to make various SLRU buffers
configurable, however, I doubt if it really solves the problem, or just
moves it to another place?

The previous patch you sent was based on some version that contained
changes for other slru buffers numbers: 'multixact_offsets_slru_buffers'
and 'multixact_members_slru_buffers'. Have you just forgot to attach
them? The patch message "[PATCH v2 2/4]" hints that you had 4 patches)
Meanwhile, I attach the rebased patch to calm down the CFbot. The
changes are trivial.

2.1) I think that both min and max values for this parameter are too
extreme. Have you tested them?

+               &multixact_local_cache_entries,
+               256, 2, INT_MAX / 2,

2.2) MAX_CACHE_ENTRIES is not used anymore, so it can be deleted.

3) No changes for third patch. I just renamed it for consistency.

--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Attachment Content-Type Size
v3-0001-Use-shared-lock-in-GetMultiXactIdMembers-for-offs.patch text/x-patch 7.6 KB
v3-0002-Make-MultiXact-local-cache-size-configurable.patch text/x-patch 3.4 KB
v3-0003-Add-conditional-variable-to-wait-for-next-MultXac.patch text/x-patch 3.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey M. Borodin 2020-08-28 18:10:34 Re: new heapcheck contrib module
Previous Message Pavel Stehule 2020-08-28 17:39:27 Re: poc - possibility to write window function in PL languages