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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Дата
Msg-id aUIvP9iZ1F6VSOYp@paquier.xyz
обсуждение исходный текст
Ответ на Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring  (Naga Appani <nagnrik@gmail.com>)
Ответы Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring
Список pgsql-hackers
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) 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?
--
Michael

Вложения

В списке pgsql-hackers по дате отправления: