Horton

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

Kirill Reshke <reshkekirill@gmail.com>

View thread
From: Kirill Reshke <reshkekirill@gmail.com>
To: Naga Appani <nagnrik@gmail.com>
Cc: pgsql-hackers@postgresql.org
Date: 2025-03-11T09:48:01Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add pg_get_multixact_stats()

  2. Add MultiXactOffsetStorageSize() to multixact_internal.h

  3. Change GetMultiXactInfo() to return the next multixact offset

  4. Widen MultiXactOffset to 64 bits

  5. Refactor ReadMultiXactCounts() into GetMultiXactInfo()

  6. Move SQL-callable code related to multixacts into its own file

  7. Split func.sgml into more manageable pieces

On Tue, 11 Mar 2025 at 14:37, Naga Appani <nagnrik@gmail.com> wrote:
>
>
>
> On Mon, Mar 10, 2025 at 10:43 AM Naga Appani <nagnrik@gmail.com> wrote:
>>
>> Hi,
>>

Hi

> =================
> Proposal
> =================
> The internal ReadMultiXactCounts() function, implemented in multixact.c, directly calculates the number of MultiXact members by reading live state from shared memory. This approach avoids the performance issues of the current filesystem-based estimation methods.

This proposal looks sane. It is indeed helpful to keep an eye out for
multixact usage in systems that are heavily loaded.

> By exposing ReadMultiXactCounts() for external use, we can provide PostgreSQL users with an efficient way to monitor MultiXact member usage. This could be particularly useful for integrating with tools like Amazon RDS Performance Insights and Amazon CloudWatch to provide enhanced database insights and proactive managed monitoring for users.
>
> Please let me know if this approach is acceptable, so I’ll go ahead and submit a patch.

Let's give it a try!



-- 
Best regards,
Kirill Reshke