Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: MultiXact\SLRU buffers configuration
From: Andrey Borodin <x4mmm@yandex-team.ru>
In-Reply-To: 
 <CA+hUKGLCLDtgDj2Xsf0uBk5WXDCeHxBDDJPsyY7m65Fde-=pyg@mail.gmail.com>
Date: Thu, 8 Apr 2021 10:24:55 +0300
Cc: Gilles Darold <gilles@darold.net>,
 Tomas Vondra <tomas.vondra@enterprisedb.com>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 Alexander Korotkov <aekorotkov@gmail.com>,
 Anastasia Lubennikova <a.lubennikova@postgrespro.ru>,
 Daniel Gustafsson <daniel@yesql.se>,
 Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B8FACD14-E3AB-4EB3-8CCC-E93697C54F72@yandex-team.ru>
References: <a7f1c4e1-1015-92a4-2bd4-6736bd13d03e@postgrespro.ru>
 <20201028013651.de5cj2xadgmba5nf@development>
 <13D8FD63-559A-4737-B7FD-05288D1CEF8B@yandex-team.ru>
 <20201028233243.ygm6yqlynkqpzekr@development>
 <43F3DE92-F236-4EA5-B4D6-39BEF6BD849D@yandex-team.ru>
 <20201029134933.xd4mh2cofuf6tdfz@development>
 <65C1B4BA-D16F-4939-978B-AC8F370F5A5E@yandex-team.ru>
 <9b4d17df-b811-8323-16be-3cab913216d1@enterprisedb.com>
 <A64B924A-B08E-417D-BD3D-D396D722053B@yandex-team.ru>
 <35862787-8b4d-a290-789e-6e12dc6527e8@enterprisedb.com>
 <13F86913-C01B-4983-AE2E-493F5A028280@yandex-team.ru>
 <6ba7eae2-8b0c-0690-11a5-e921e6586180@darold.net>
 <3F5E23A3-6250-486E-9CCA-E2A5B6A28B4F@yandex-team.ru>
 <636f694a-4d69-d6d9-78d1-c88714f3e2e0@darold.net>
 <3319917a-679e-b07d-b194-473552b72082@darold.net>
 <d6f17699-0c18-1a47-8dfb-f52b36fb7c4f@darold.net>
 <D2CC4D64-CA89-411B-96D7-F0A4BF4BB895@yandex-team.ru>
 <b4911e88-9969-aaba-f6be-ed57bd5fec36@darold.net>
 <1E3DD5BF-A54E-4203-86C5-94C9EFA0E095@yandex-team.ru>
 <04ae150b-6442-148a-bb23-77082f6fca1d@darold.net>
 <3768803E-4794-409D-88D2-C3EF7CA1B7FC@yandex-team.ru>
 <CA+hUKGJ4TwipnMDmKdORu4zUo_rofsuu5FQsgV=UHJ3bY38ERw@mail.gmail.com>
 <CA+hUKGK2bkx91=CWRuPqWdXAu2JSS0mDPBh8DNuSeKhy8eOLgg@mail.gmail.com>
 <CA+hUKGL0g+Nmf=2XePaXtw82BkW9CRzoxxXB4gqZOk7tHxNJXg@mail.gmail.com>
 <D330C01E-789A-4DDD-B2B1-4561B8B7F41D@yandex-team.ru>
 <75B95FDD-2BE0-4525-8BDD-FC67C8BCBD53@yandex-team.ru>
 <CA+hUKGKVqrxOp82zER1=XN=yPwV_-OCGAg=ez=1iz9rG+A7Smw@mail.gmail.com>
 <88CB7042-6181-4EF4-8B25-61EC5E5725D4@yandex-team.ru>
 <CA+hUKGJubZLN16cTJjaeEpWdaTsKYuLaV67N+0Mps521zYo6ig@mail.gmail.com>
 <018EF641-FC9D-4BA9-A458-6842E27E91C2@yandex-team.ru>
 <B8AC2998-942F-40F0-ADDD-7846C6AE7705@yandex-team.ru>
 <CA+hUKGKEdeVKpOqBxzRF+Z4=j0T+CA7ERrXni5De71Mm6-dBWA@mail.gmail.com>
 <27D90FFC-B897-4BC5-B4F5-9047B9886AA3@yandex-team.ru>
 <CA+hUKGKTESKn9-BkUT8T3vwcgZQJqsV4PSQKpE+M1qUgfSTLMg@mail.gmail.com>
 <B7D61584-6CAC-4CF9-B3D4-7CC52D6C4C5C@yandex-team.ru>
 <15CA416B-3446-462D-902B-4883DD3ADEE6@yandex-team.ru>
 <CA+hUKGLCLDtgDj2Xsf0uBk5WXDCeHxBDDJPsyY7m65Fde-=pyg@mail.gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/B8FACD14-E3AB-4EB3-8CCC-E93697C54F72%40yandex-team.ru>
Precedence: bulk


> 8 =D0=B0=D0=BF=D1=80. 2021 =D0=B3., =D0=B2 03:30, Thomas Munro =
<thomas.munro@gmail.com> =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0=
):
>=20
> Here's another approach that is a little less exciting than
> "tournament RR" (or whatever that should be called; I couldn't find an
> established name for it).  This version is just our traditional linear
> search, except that it stops at 128, and remembers where to start from
> next time (like a sort of Fisher-Price GCLOCK hand).  This feels more
> committable to me.  You can argue that all buffers above 128 are bonus
> buffers that PostgreSQL 13 didn't have, so the fact that we can no
> longer find the globally least recently used page when you set
> xact_buffers > 128 doesn't seem too bad to me, as an incremental step
> (but to be clear, of course we can do better than this with more work
> in later releases).
I agree that this version of eviction seems much more effective and less =
intrusive than RR. And it's still LRU, which is important for subsystem =
that is called SLRU.
shared->search_slotno is initialized implicitly with memset(). But this =
seems like a common practice.
Also comment above "max_search =3D Min(shared->num_slots, =
MAX_REPLACEMENT_SEARCH);" does not reflect changes.

Besides this patch looks good to me.

Thanks!

Best regards, Andrey Borodin.=