Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring

Thanks for the suggestion and review, Michael and Ashutosh!

On Tue, Dec 16, 2025 at 11:17 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> wrote:
>
> On Wed, Dec 17, 2025 at 9:49 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> >
> > On Sat, Dec 13, 2025 at 01:34:47PM -0600, Naga Appani wrote:
> > >
> > > I validated the behavior before and after cleanup.
> > > The function correctly reports current usage (beyond the old limits) and
> > > resets once multixacts are removed:
> >
> > + /*
> > + * Calculate storage space for members. Members are stored in groups,
> > + * with each group containing MULTIXACT_MEMBERS_PER_MEMBERGROUP members
> > + * and taking MULTIXACT_MEMBERGROUP_SIZE bytes.
> > + */
> > + membersBytes = (int64) (members / MULTIXACT_MEMBERS_PER_MEMBERGROUP) *
> > + 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.
>
> --
> Best Wishes,
> Ashutosh Bapat

I’ve updated the patch as suggested.

The member storage size calculation has been refactored into a static
inline function, MultiXactMemberStorageSize(), in
src/include/access/multixact_internal.h.

Please find v13 attached.

Regards,
Naga