Message-ID: <002034bdb202a87b97de38648b0e35d8ac6db0ac.camel@cybertec.at>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Gabriel Guillem =?ISO-8859-1?Q?Barcel=F3?= Soteras
	 <gbarcelo@parlamentib.es>, Pgsql-admin <pgsql-admin@lists.postgresql.org>
Date: Tue, 13 Jan 2026 18:26:46 +0100
In-Reply-To: 
 <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
References: 
	<DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.2 (3.58.2-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/002034bdb202a87b97de38648b0e35d8ac6db0ac.camel%40cybertec.at>
Precedence: bulk

On Tue, 2026-01-13 at 08:19 +0000, Gabriel Guillem Barcel=C3=B3 Soteras wro=
te:
> We have a healthy PostgreSQL 15 instance (installed from the official Pos=
tgres repository)
> running on Red Hat 9. It serves several databases for internal SMB applic=
ations.
> The environment is stable=E2=80=94apps perform well, disk usage is fine, =
and the system is not
> under heavy load.
>=20
> After integrating PostgreSQL into our monitoring system, I noticed warnin=
gs related to VACUUM
> and ANALYZE. Some tables have never undergone these maintenance operation=
s, or the last run
> was 30=E2=80=93200 days ago. These databases have very few deletions, and=
 many tables show no growth
> at all=E2=80=94typical 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?
>=20
> We=E2=80=99re also monitoring table bloat, which is currently under 1%, s=
uggesting that manual
> intervention may not be necessary and that autovacuum is doing its job wh=
en needed.

I'd call this a false positive warning from the monitoring system, and ther=
e 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.r=
eltuples + 50
   (that would indicate that autovacuum doesn't trigger, is too slow or can=
not 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