public inbox for [email protected]  

help / color / mirror / Atom feed

From: Laurenz Albe <[email protected]>
To: Gabriel Guillem Barceló Soteras <[email protected]>
To: Pgsql-admin <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Date: Tue, 13 Jan 2026 18:26:46 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
References: <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>

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

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox