public inbox for [email protected]
help / color / mirror / Atom feedFrom: =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
To: [email protected] <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Date: Wed, 14 Jan 2026 07:42:16 +0000
Message-ID: <DU0PR08MB79213FAA21D2EA1C915529C2A68FA@DU0PR08MB7921.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <[email protected]>
References: <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
<[email protected]>
<[email protected]>
https://www.pgadmin.org/support/list/
Go to PGLister Management link...
From: Rich Meyer <[email protected]>
Date: Tuesday, 13 January 2026 at 18:30
To: Laurenz Albe <[email protected]>
Cc: Gabriel Guillem Barceló Soteras <[email protected]>, Pgsql-admin <[email protected]>
Subject: 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
[email protected]<mailto:[email protected]>
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
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: <DU0PR08MB79213FAA21D2EA1C915529C2A68FA@DU0PR08MB7921.eurprd08.prod.outlook.com>
* 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