MIME-Version: 1.0
Date: Tue, 13 Jan 2026 12:30:24 -0500
From: Rich Meyer <rmeyer@sevroconsulting.com>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: =?UTF-8?Q?Gabriel_Guillem_Barcel=C3=B3_Soteras?=
 <gbarcelo@parlamentib.es>, Pgsql-admin <pgsql-admin@lists.postgresql.org>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
In-Reply-To: <002034bdb202a87b97de38648b0e35d8ac6db0ac.camel@cybertec.at>
References: 
 <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
 <002034bdb202a87b97de38648b0e35d8ac6db0ac.camel@cybertec.at>
Message-ID: <0225023895511123aac84ea16daa1363@sevroconsulting.com>
Content-Type: multipart/alternative;
 boundary="=_d60229e29657416bce6f2d4432c78db8"
Archived-At: 
 <https://www.postgresql.org/message-id/0225023895511123aac84ea16daa1363%40sevroconsulting.com>
Precedence: bulk

--=_d60229e29657416bce6f2d4432c78db8
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=UTF-8;
 format=flowed

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

---
Rich Meyer
Sevro Consulting
rmeyer@sevroconsulting.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
--=_d60229e29657416bce6f2d4432c78db8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt; font-family: Verdana,Gen=
eva,sans-serif'>
<p>Hi, sorry about this but I cannot for the life of me unsubscribe from th=
ese emails. Can anyone help?<br /><br /><br /></p>
<div id=3D"signature">---<br />
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
Rich Meyer<br />Sevro Consulting<br /><a href=3D"mailto:rmeyer@sevroconsult=
ing.com">rmeyer@sevroconsulting.com</a><br />732-991-6249</div>
</div>
<br />
<p id=3D"reply-intro">On 2026-01-13 12:26 pm, Laurenz Albe wrote:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
On Tue, 2026-01-13 at 08:19 +0000, Gabriel Guillem Barcel&oacute; Soteras w=
rote:
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0">We have a healthy PostgreSQL 15 instance (installed fr=
om the official Postgres repository)<br />running on Red Hat 9. It serves s=
everal databases for internal SMB applications.<br />The environment is sta=
ble&mdash;apps perform well, disk usage is fine, and the system is not<br /=
>under heavy load.<br /><br />After integrating PostgreSQL into our monitor=
ing system, I noticed warnings related to VACUUM<br />and ANALYZE. Some tab=
les have never undergone these maintenance operations, or the last run<br /=
>was 30&ndash;200 days ago. These databases have very few deletions, and ma=
ny tables show no growth<br />at all&mdash;typical for internal SMB apps.<b=
r />I know this topic comes up often, but should I schedule a monthly VACUU=
M + ANALYZE via a cron<br />or systemd timer, while still keeping autovacuu=
m enabled?<br /><br />We&rsquo;re also monitoring table bloat, which is cur=
rently under 1%, suggesting that manual<br />intervention may not be necess=
ary and that autovacuum is doing its job when needed.</blockquote>
<br />I'd call this a false positive warning from the monitoring system, an=
d there is nothing<br />you have to do except to disable this test. &nbsp;I=
t is perfectly healthy for a table with<br />few updates and deletes to ve =
autovacuumed very rarely.<br /><br />What you should monitor is<br /><br />=
a) whether pg_stat_all.tables.n_dead_tup is much more than 0.2 * pg_class.r=
eltuples + 50<br />&nbsp; &nbsp;(that would indicate that autovacuum doesn'=
t trigger, is too slow or cannot make any<br />&nbsp; &nbsp;progress owing =
to long-running transactions)<br /><br />b) whether age(pg_class.relfrozenx=
id) exceeds 300 million<br />&nbsp; &nbsp;(that would indicate a problem wi=
th anti-wraparound autovacuum)<br /><br />Yours,<br />Laurenz Albe<br /><br=
 /><br /></div>
</blockquote>
</body></html>

--=_d60229e29657416bce6f2d4432c78db8--