MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Date: Fri, 22 Aug 2025 09:28:49 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: Naga Appani <nagnrik@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Ashutosh Bapat
 <ashutosh.bapat.oss@gmail.com>, Kirill Reshke <reshkekirill@gmail.com>,
 pgsql-hackers@postgresql.org
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
In-Reply-To: 
 <CA+QeY+AwWV=g8z1eDE7OGHxKBer18gVER7nD+SnfhqLmiL7NOA@mail.gmail.com>
References: 
 <CALdSSPi3Gh08NtcCn44uVeUAYGOT74sU6uei_06qUTa5rMK43g@mail.gmail.com>
 <CA+QeY+DTggHskCXOa39nag2sFds9BD-7k__zPbvL-_VVyJw7Sg@mail.gmail.com>
 <CAExHW5uxBnodmpXygUQUxZAyxYvbXczadxGOVeL=0DxpkXUR-g@mail.gmail.com>
 <aIb67MiYhVy7gwV-@paquier.xyz>
 <CAExHW5vba_ecL2c27giAOOaRxoNdVX2BNQVCN4PFOZJC17NrqQ@mail.gmail.com>
 <CA+QeY+CFLjh0gb-j9p+0eJK=r19izhEPCBY3ns4+HCgOQojh8Q@mail.gmail.com>
 <CAExHW5s5hnxKK_VE=q94sN8uU5BJCRpAescGuamheuM-Ua559A@mail.gmail.com>
 <CA+QeY+C3tc12wWX56yHozLYK=MmCkn1fODzFWC6-dSY+TZghTQ@mail.gmail.com>
 <CAExHW5s-StFwDpZBeiikvdnrBBr0s+2jJTZRv3Hh914T4C6Euw@mail.gmail.com>
 <CA+QeY+AmRSSJU8GKJ1uNVe2ps8GTONXpioYR7gEz91_prKR6sw@mail.gmail.com>
 <aKQac2ZrY4UWBORR@paquier.xyz>
 <CA+QeY+AwWV=g8z1eDE7OGHxKBer18gVER7nD+SnfhqLmiL7NOA@mail.gmail.com>
User-Agent: Roundcube Webmail/1.4.11
Message-ID: <a5f1b794396a79d69ec70f5eaa7bdaf3@oss.nttdata.com>
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/a5f1b794396a79d69ec70f5eaa7bdaf3%40oss.nttdata.com>
Precedence: bulk

On 2025-08-20 13:27, Naga Appani wrote:

Thanks for working on this!

> On Tue, Aug 19, 2025 at 1:32=E2=80=AFAM Michael Paquier <michael@paquie=
r.xyz>=20
> wrote:
>> FWIW, I think that you should be a bit more careful before sending
>> updated patch sets.  You have missed an extra point I have raised
>> upthread about the refactoring pieces: the switch from
>> ReadMultiXactCounts() to GetMultiXactInfo() can be done in a patch of
>> its own.
>>=20
>> So I have extracted this part from your latest patch, and applied it
>> independently of the SQL function business.  Now we are in an
>> advantageous position on HEAD: even if we do not conclude about the
>> SQL function to show the mxact numbers and offsets, we have the
>> function that gives an access to the data you are looking for.  In
>> short, it is now possible to provide an equivalent of the feature you
>> want outside of core.  Not saying that the patch cannot be useful, but
>> such refactoring pieces open more possibilities, and offer a cleaner
>> commit history with less churn in the main patches.
>> --
>=20
> Thanks for the review and separating the refactoring into its own=20
> commit.
> Point taken on being more careful when sending updated patch sets.
> I=E2=80=99ll make sure to keep
> refactoring and SQL layer changes clearly separated going forward.
>=20
> Attached is v6, rebased on top of HEAD. This version is limited to the
> SQL function only.
>=20

diff --git a/doc/src/sgml/maintenance.sgml=20
b/doc/src/sgml/maintenance.sgml
index e7a9f58c015..6f0e8d7c10a 100644
--- a/doc/src/sgml/maintenance.sgml
+++ b/doc/src/sgml/maintenance.sgml
@@ -813,12 +813,56 @@ HINT:  Execute a database-wide VACUUM in that=20
database.
      <para>
       As a safety device, an aggressive vacuum scan will
       occur for any table whose multixact-age is greater than <xref
-     linkend=3D"guc-autovacuum-multixact-freeze-max-age"/>.  Also, if th=
e
-     storage occupied by multixacts members exceeds about 10GB,=20
aggressive vacuum
+     linkend=3D"guc-autovacuum-multixact-freeze-max-age"/>. Also, if the=
=20
number
+     of members created exceeds approximately 2^31 entries, aggressive=20
vacuum
       scans will occur more often for all tables, starting with those=20
that

Looking at commit ff20ccae9fdb, it seems that the documentation was=20
intentionally written in terms of gigabytes rather than the number:

> The threshold is two billion members, which was interpreted as 2GB
> in the documentation. Fix to reflect that each member takes up five
> bytes, which translates to about 10GB. This is not exact, because of
> page boundaries. While at it, mention the maximum size 20GB.

Anyway, I also think, as Ashutosh suggested, that if we want to fix this=20
documentation, it would be better to do so in a separate patch.

--=20
Regards,

--
Atsushi Torikoshi
Seconded from NTT DATA Japan Corporation to SRA OSS K.K.