Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance

Hi, sorry about this but I cannot for the life of me unsubscribe from
these emails. Can anyone help?

---
Rich Meyer
Sevro Consulting
rmeyer(at)sevroconsulting(dot)com
732-991-6249
On 2026-01-13 12:26 pm, Laurenz Albe wrote:

> On Tue, 2026-01-13 at 08:19 +0000, Gabriel Guillem Barceló Soteras
> wrote:
>
>> We have a healthy PostgreSQL 15 instance (installed from the official
>> Postgres repository)
>> running on Red Hat 9. It serves several databases for internal SMB
>> applications.
>> The environment is stable--apps perform well, disk usage is fine, and
>> the system is not
>> under heavy load.
>>
>> After integrating PostgreSQL into our monitoring system, I noticed
>> warnings related to VACUUM
>> and ANALYZE. Some tables have never undergone these maintenance
>> operations, or the last run
>> was 30-200 days ago. These databases have very few deletions, and many
>> tables show no growth
>> at all--typical for internal SMB apps.
>> I know this topic comes up often, but should I schedule a monthly
>> VACUUM + ANALYZE via a cron
>> or systemd timer, while still keeping autovacuum enabled?
>>
>> We're also monitoring table bloat, which is currently under 1%,
>> suggesting that manual
>> intervention may not be necessary and that autovacuum is doing its job
>> when needed.
>
> I'd call this a false positive warning from the monitoring system, and
> there is nothing
> you have to do except to disable this test. It is perfectly healthy
> for a table with
> few updates and deletes to ve autovacuumed very rarely.
>
> What you should monitor is
>
> a) whether pg_stat_all.tables.n_dead_tup is much more than 0.2 *
> pg_class.reltuples + 50
> (that would indicate that autovacuum doesn't trigger, is too slow or
> cannot make any
> progress owing to long-running transactions)
>
> b) whether age(pg_class.relfrozenxid) exceeds 300 million
> (that would indicate a problem with anti-wraparound autovacuum)
>
> Yours,
> Laurenz Albe