From: Gabriel Guillem Barceló Soteras <gbarcelo@parlamentib.es> Date: Thursday, 15 January 2026 at 09:16 To: Ron Johnson <ronljohnsonjr@gmail.com> Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Oh god sorry, the site seemed postgresql.org like
From: Ron Johnson <ronljohnsonjr@gmail.com> Date: Wednesday, 14 January 2026 at 16:03 To: Gabriel Guillem Barceló Soteras <gbarcelo@parlamentib.es> Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
lol no. That's for PG Admin IV, not the pgsql-admin list.
On Wed, Jan 14, 2026 at 2:42 AM Gabriel Guillem Barceló Soteras <gbarcelo@parlamentib.es> 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)
