Re: do only critical work during single-user vacuum? - Mailing list pgsql-hackers

From Bossart, Nathan
Subject Re: do only critical work during single-user vacuum?
Date
Msg-id 4666164C-027D-4C09-96E6-1EDAF167B421@amazon.com
Whole thread Raw
In response to Re: do only critical work during single-user vacuum?  (John Naylor <john.naylor@enterprisedb.com>)
List pgsql-hackers
On 1/21/22, 2:43 PM, "John Naylor" <john.naylor@enterprisedb.com> wrote:
> - to have a simple, easy to type, command

AFAICT the disagreement is really just about the grammar.
Sawada-san's idea would look something like

        VACUUM (FREEZE, INDEX_CLEANUP OFF, MIN_XID_AGE 1600000000, MIN_MXID_AGE 1600000000);

while your proposal looks more like

        VACUUM (WRAPAROUND);

The former is highly configurable, but it is probably annoying to type
at 3 AM, and the interaction between the two *_AGE options is not
exactly intuitive (although I expect MIN_XID_AGE to be sufficient in
most cases).  The latter is not as configurable, but it is much easier
to type at 3 AM.

I think simplicity is a good goal, but I don't know if the difference
between the two approaches outweighs the benefits of configurability.
If you are in an emergency situation, you already will have to take
down the server, connect in single-user mode to the database(s) that
need vacuuming, and actually do the vacuuming.  The wraparound
WARNING/ERROR already has a HINT that describes the next steps
required.  Perhaps it would be enough to also emit an example VACUUM
command to use.

I think folks will find the configurability useful, too.  With
MIN_XID_AGE, it's super easy to have pg_cron vacuum everything over
500M on the weekend (and also do index cleanup), which may allow you
to use more relaxed autovacuum settings during the week.  The docs
already have suggestions for manually vacuuming when the load is low
[0], so I think it is reasonable to build additional support for this
use-case.

Nathan

[0] https://www.postgresql.org/docs/devel/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY


pgsql-hackers by date:

Previous
From: James Coleman
Date:
Subject: Re: Document atthasmissing default optimization avoids verification table scan
Next
From: James Coleman
Date:
Subject: Re: Document atthasmissing default optimization avoids verification table scan