Re: Doc fix of aggressive vacuum threshold for multixact members storage - Mailing list pgsql-hackers

From Alex Friedman
Subject Re: Doc fix of aggressive vacuum threshold for multixact members storage
Date
Msg-id CACbFw61zQM1rb8AJwXZZM973gDbwa6Q6fC3o_ZXXre+Hm5baiA@mail.gmail.com
Whole thread Raw
In response to Re: Doc fix of aggressive vacuum threshold for multixact members storage  (Sami Imseih <samimseih@gmail.com>)
Responses Re: Doc fix of aggressive vacuum threshold for multixact members storage
List pgsql-hackers
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.

> 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.

Thanks,

Alex



pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: Doc fix of aggressive vacuum threshold for multixact members storage
Next
From: Tom Lane
Date:
Subject: Re: Using Expanded Objects other than Arrays from plpgsql