MIME-Version: 1.0
References: 
 <CAExHW5sFtNduYEnyGhQOb=xiLrbkvwE0merhpZA5pNqcNzBbmw@mail.gmail.com>
 <CA+QeY+C38cgqesZi1Tt92=D6rw_RzCV5yKhoDe5eFLtQ9RQB_Q@mail.gmail.com>
 <29f9e7abc90c3a4fe4a44026141c0d6c@oss.nttdata.com>
 <CABPTF7WfTDdhZbHBgoqo=uGP_DZO-xO1bX5BfkwjgHK9jU+tOA@mail.gmail.com>
 <95850ce1-2d5e-4271-92ea-c2a02e36b303@vondra.me>
 <CA+QeY+Aja_=j1EuY87L06KaPO4EJqqkS4B+Vg9AsWnGM1d_VRA@mail.gmail.com>
 <CAExHW5vDJ526OXv+Hk-=TxPoiL7RR+k+xSF2tyNqtaJHC5aoDQ@mail.gmail.com>
 <CA+QeY+CF2q2M51k5t4rZZ2SNeEq8ORf3Dr8T1+jm72VsHRJfjw@mail.gmail.com>
 <CAExHW5shToKbeiw1eRGeiSyVeCYZUJyw2KUtBKYFn0J3dCGzbA@mail.gmail.com>
 <CA+QeY+CqRjUj93_kV0YmMBqfkgo4WGEoiYOaP_wCMoJ8FOKpog@mail.gmail.com>
 <aUIvP9iZ1F6VSOYp@paquier.xyz>
In-Reply-To: <aUIvP9iZ1F6VSOYp@paquier.xyz>
From: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Date: Wed, 17 Dec 2025 10:46:51 +0530
Message-ID: 
 <CAExHW5t-di9g+S-7pdXxCA8z3AtCWYn_=Ou9fY0aMg7K0wA2KA@mail.gmail.com>
Subject: Re: [Proposal] Expose internal MultiXact member count function for
 efficient monitoring
To: Michael Paquier <michael@paquier.xyz>
Cc: Naga Appani <nagnrik@gmail.com>, Tomas Vondra <tomas@vondra.me>,
	Xuneng Zhou <xunengzhou@gmail.com>, torikoshia <torikoshia@oss.nttdata.com>,
	Kirill Reshke <reshkekirill@gmail.com>, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAExHW5t-di9g%2BS-7pdXxCA8z3AtCWYn_%3DOu9fY0aMg7K0wA2KA%40mail.gmail.com>
Precedence: bulk

On Wed, Dec 17, 2025 at 9:49=E2=80=AFAM Michael Paquier <michael@paquier.xy=
z> wrote:
>
> On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> > Documentation changes:
> > - Removed the NULL-return discussion from func-info.sgml, as the
> >   statistics are now always available.
> > - Updated maintenance.sgml to clarify that exceeding the historical
> >   2^32 member limit no longer causes wraparound, but instead triggers
> >   more aggressive vacuum activity for disk space management.
> >
> > I validated the behavior before and after cleanup.
> > The function correctly reports current usage (beyond the old limits) an=
d
> > resets once multixacts are removed:
>
> +       /*
> +        * Calculate storage space for members. Members are stored in gro=
ups,
> +        * with each group containing MULTIXACT_MEMBERS_PER_MEMBERGROUP m=
embers
> +        * and taking MULTIXACT_MEMBERGROUP_SIZE bytes.
> +        */
> +       membersBytes =3D (int64) (members / MULTIXACT_MEMBERS_PER_MEMBERG=
ROUP) *
> +                                  MULTIXACT_MEMBERGROUP_SIZE;
>
> This is the key point of the patch internal logic.  And there is one
> thing that I am wondering here.  The amount of space taken by a number
> of members depends on the other compiled constants from
> multixact_internal.h.  Hence, rather than calculate the amount of
> space taken by a set of members in some code hidden in the SQL
> function, could it be better to put that directly as a macro or an
> inline function in multixact_internal.h?

+1.

--=20
Best Wishes,
Ashutosh Bapat