Thread
-
Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Naga Appani <nagnrik@gmail.com> — 2025-03-11T05:15:28Z
On Mon, Mar 10, 2025 at 10:43 AM Naga Appani <nagnrik@gmail.com> wrote: > Hi, > > I would like to propose exposing an internal PostgreSQL function called > ReadMultiXactCounts() to allow for efficient monitoring of MultiXact > member usage. This function provides an accurate, real-time view of > MultiXact activity by directly retrieving the actual member count, rather > than relying on storage-based calculations. > > *Current Challenges: *The existing approach we are currently using to > estimate MultiXact member usage has several drawbacks: > > - *Filesystem scanning overhead: *These functions recursively scan the > pg_multixact directory, iterating over potentially thousands or > millions of files, and retrieving file sizes using stat() calls, which > introduces significant I/O overhead. > - *Potential performance bottleneck:* On systems with high transaction > throughput generating large numbers of MultiXact members, the > filesystem-based approach scales poorly due to the latency of stat() calls, > especially on network-based filesystems like RDS/Aurora. > - *Not a real-time or memory-efficient solution:* The current approach > does not provide a direct, in-memory view of MultiXact activity. > > *Proposed Solution*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. > ................ > ............... > My apologies for re-posting. This is my first time writing to the hackers list, and I accidentally used HTML formatting. Below is the original request in plain text: ************************************************************************************************************************************************************** I would like to propose exposing an internal PostgreSQL function called ReadMultiXactCounts()[1] to allow for efficient monitoring of MultiXact member usage. This function provides an accurate, real-time view of MultiXact activity by directly retrieving the actual member count, rather than relying on storage-based calculations. ================ Current Challenges ================ The existing approach we are currently using to estimate MultiXact member usage has several drawbacks: - Filesystem scanning overhead: These functions recursively scan the pg_multixact directory, iterating over potentially thousands or millions of files, and retrieving file sizes using stat() calls, which introduces significant I/O overhead. - Potential performance bottleneck: On systems with high transaction throughput generating large numbers of MultiXact members, the filesystem-based approach scales poorly due to the latency of stat() calls, especially on network-based filesystems like RDS/Aurora. - Not a real-time or memory-efficient solution: The current approach does not provide a direct, in-memory view of MultiXact activity. ================= 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. 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. ========================= Performance comparison ========================= The performance comparison between the current and proposed approaches shows a significant improvement, with the proposed solution taking only a fraction of a millisecond to retrieve the MultiXact member count, compared to tens or hundreds of milliseconds for the current filesystem-based approach. And as more members are generated, the gap widens. Following is the comparison of performance between calculating storage of MultiXact members directory and retrieving the count of members. Implementation | Used size | MultiXact members ----------------------------------------------------+-------------+------------------ EC2 community (RDS version of pg_ls_multixactdir) | 8642 MB | 1.8 billion Linux du command | 8642 MB | 1.8 billion Proposal (ReadMultiXactCounts) | 8642 MB | 1.8 billion ============================================================================================ Sample runs ============================================================================================ Using "du -h" -------------------- postgres=# \! time du -h /rdsdbdata/db/17.4/data/pg_multixact/members 13G /rdsdbdata/db/17.4/data/pg_multixact/members real 0m0.285s <============================= time taken user 0m0.050s <============================= time taken sys 0m0.140s Using RDS's pg_ls_multixactdir (): ------------------------------------------------------------ postgres=# SELECT pg_size_pretty(coalesce(sum(size), 0)) AS members_size FROM pg_ls_multixactdir () WHERE name LIKE 'pg_multixact/members%'; members_size -------------- 13 GB (1 row) Time: 226.533 ms <============================= time taken Using proposed function: ---------------------------------------- postgres=# SELECT to_char(pg_get_multixact_members_count(), '999,999,999,999') AS members_count; members_count ------------------ 2,745,823,171 (1 row) Time: 0.142 ms <============================= time taken ============================================================================================ I believe exposing ReadMultiXactCounts() would be a valuable addition to the PostgreSQL ecosystem, providing users with a more reliable and efficient way to monitor MultiXact usage. Appreciate your feedback or discussion on this proposal. Please let me know if this approach is acceptable, so I’ll go ahead and submit a patch. Thank you! References: [1] https://github.com/postgres/postgres/blob/master/src/backend/access/transam/multixact.c#L2925-L2948 > > Thank you! > > Best regards, > Naga Appani > Postgres Database Engineer > Amazon Web Services >