From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: do only critical work during single-user vacuum? |
Date: | 2022-01-21 23:32:57 |
Message-ID: | 4666164C-027D-4C09-96E6-1EDAF167B421@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/21/22, 2:43 PM, "John Naylor" <john(dot)naylor(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2022-01-22 00:14:36 | Re: Document atthasmissing default optimization avoids verification table scan |
Previous Message | James Coleman | 2022-01-21 23:29:04 | Re: Document atthasmissing default optimization avoids verification table scan |