On Mon, Feb 3, 2025 at 11:29 AM Alex Friedman <alex...@gmail.com> wrote: > > Hi Sami, > > Thanks for the feedback. > > > 1/ Remove this as > > "(50% of the maximum, which is about 20GB)," > > > > [1] tried to avoid explaining this level of detail, and I > > agree with that. > > I feel it is critical for users to know what is the hard limit of > multixact members. As PG doesn't (yet) expose how many multixact > members are in use, the only way for users to know the distance to > members wraparound is by monitoring the members directory space usage. > So it seems to me that the 20 GB number is very important to have in > the docs.
A few paragraphs up the docs, there is this mention: ". There is a separate storage area which holds the list of members in each multixact, which also uses a 32-bit counter and which must also be managed." Maybe we can add more to this paragraph, such as: "also be managed. This member can grow to 20GB" And then in the proposed correction: " Also, if the storage occupied by multixacts members area exceeds 10GB (50% of the maximum the members area can grow), aggressive vacuum scans will occur more often for all tables " What do you think? > > 2/ c/"about 10GB"/"10GB" the "about" does not seem necessary here. > > The threshold is actually ~10.015 GiB (due to the 12 bytes wasted per > 8KB page), or ~10.75 GB, so to avoid confusion by users when > aggressive autovacuum doesn't trigger exactly at 10GB, I believe we > should either be exact, or say that we are not being exact. Being > exact is difficult as it depends on the block size. And as I looked > through the doc page in question, I noticed there are already several > cases using the "about" wording, e.g. "about 50MB of pg_xact storage" > and "about 2GB of pg_commit_ts storage", so here I went for > consistency with the rest of the doc. I really don't have a strong opinion about this, except it seemed unnecessary. But if it helps clarify that it's not an exact 10GB, I am ok with keeping it. Regards, Sami
