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 по дате отправления: