From: =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?=
	<gbarcelo@parlamentib.es>
To: Paul Smith* <paul@pscs.co.uk>
CC: "pgsql-admin@lists.postgresql.org" <pgsql-admin@lists.postgresql.org>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Thread-Topic: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Thread-Index: AQHchGJXKjS2rQK4KU+5eKwTs92TzrVP2DqAgAAFqLc=
Date: Tue, 13 Jan 2026 11:09:58 +0000
Message-ID: 
 <DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
References: 
 <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
 <81c12173-6da4-43e9-866a-00321a00415a@pscs.co.uk>
In-Reply-To: <81c12173-6da4-43e9-866a-00321a00415a@pscs.co.uk>
Accept-Language: es-ES, en-GB, en-US
Content-Language: en-GB
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?/8jsyxakzB+uFaIL+n0KiMyGpk2XjXjQf5XGo3LgsMzj5OitgVk9Vo2x?=
 =?Windows-1252?Q?hjDjCLZzVT1JRfmp+cEX3FNHpo6H9Z9mT86suJb6JXH3aPMgrBHmG/kO?=
 =?Windows-1252?Q?JIHyNJ+jOs09EhSR47WDAausRaz+xssmRA9tXWSpYEwD/m0vwU9METnK?=
 =?Windows-1252?Q?aYViCbWeqitOQ1+W2lxHXGQxWuYb6/SkEkvNPdLYpznXm3rHJbZePIwI?=
 =?Windows-1252?Q?AQ0WfLFoN8KU9g8/ioC1dDpmgECMJVftIzV/pIhqXHqvg50Fhz0f9X4a?=
 =?Windows-1252?Q?R9CKxA5rvC/UgHVW4GorGSF/wlKj4xb5HnhWgGLohNEjeQHlarb+UqB5?=
 =?Windows-1252?Q?IVAF4QuJKsfD1r0EzWWHn6bzfzgKIynbzciT/tkAwj687kt37sZdofrb?=
 =?Windows-1252?Q?fjAhyOXwNcyjOnNP46DrZzpzBL9DH+h2+aeeb7JbD+ZvnblVajzgI067?=
 =?Windows-1252?Q?COa8WSUz2TMa93h3gLtMjxEhkDYH7h3Qmw4DkyKePUdJ8qSAiMijjqRN?=
 =?Windows-1252?Q?Do9lGmW9QY8bLl4/ECU8QSBxK/CD5osFEYKXnmeTKn9j9A6a1S9L7ClL?=
 =?Windows-1252?Q?ifjGrzheE3Lc9OgmJfcTQIOgFmAZRjdiCjLkYSakNnLLhiTuz7qoucwn?=
 =?Windows-1252?Q?NOiL9Rpp2jcS994Fsm48yPr42xxzWzHrIiAo5aV4n08idCeSVqOnP13X?=
 =?Windows-1252?Q?P7yG87EQxvMLAoD1HMJUDwp/XkWduv9vgGUMbs3mr8/Wh8wP6elYR/s8?=
 =?Windows-1252?Q?ckd9RaCz6l8Hc4CZRO87i2xLSTQlnxiUt7u3rBsj1Nw8rdVriSOTZ8V5?=
 =?Windows-1252?Q?2UXvmuYzPSdTQNw7g0NzpIJAUlQvg5u9c5F7oClbiXfP8xPY7R/PaNJ1?=
 =?Windows-1252?Q?owsakNLuP2iVg4rXFrnpUoSf0mobBaqgdv5cruYzGfpyW5/sxaF3q7dA?=
 =?Windows-1252?Q?Ay0JtwdzPymoj6EYDDgvTwDzENdk1QwcKMAcuZhb07UzGkSK2V58HhYM?=
 =?Windows-1252?Q?3OhxnlJNhTJOEwQ0TAdfWBdFFvb2Wjc/j7iDAaz/mgWp/ChPxJWhGjuZ?=
 =?Windows-1252?Q?XvQnqzMVo5Dqo/jQfEO2+TWnK9U0jqnTl9ZB1o5IxrQZxz04Qwih1hWE?=
 =?Windows-1252?Q?0J3RAEdqeLJJU+QOhUdS8bKwtGHotKNQIlszzboLFtVZa/OJltxDpFUH?=
 =?Windows-1252?Q?GlIcoB/LZyczkdeH55VsTcnewjs9WbhHN/hJs9zbhSBOrlsXpThjOl6S?=
 =?Windows-1252?Q?9pCPWedW89l1iwmA1Fo+gP8Zmapv7Lu2i357VuQS3L9vBqx7qmNfLzm9?=
 =?Windows-1252?Q?iJl6IlV805w7PQ2AherqC9Mn7iOsNoWBhamDMhFuc7OTZ3Mq3awKZqvL?=
 =?Windows-1252?Q?1uXVNzFbZO//XD99xHWTKkb10ckyPwKVH4W257T5lCBfwYRT15XVJJte?=
 =?Windows-1252?Q?DcqJu5iknSI7dB1aLNDQLm4f2kMLZtrC183n3iJZCBy50VBpnaxUMesx?=
 =?Windows-1252?Q?DPULnBuyTEas51JyrcW/GjUD4P001U5d/XSq5q6vdZHPV8D/fpvEdfKy?=
 =?Windows-1252?Q?ts4yVU5vOn1knBERZVvX0UEU/haGAB6F7rmihQUnV1lodwd5mjI1WaPj?=
 =?Windows-1252?Q?27jy0sWTs2ItzlZJ0FLJhLEqkME54RQRLKGRNiYJIKWJ7nRfRPF4MHa2?=
 =?Windows-1252?Q?70l1fbpnfnqmB+n3yWzL52KQsFa3r0nWSCmkTNU3dpU7jQ2Why2MHEwf?=
 =?Windows-1252?Q?wLtokW/YXHw2ld9Tp1Fln8gLK0DzjhoDOaYO3+lFwyB150O9g9puxGaR?=
 =?Windows-1252?Q?YPE2ej4AbSz5RHtoesVNXIG2oANuoEIw1/kBoZu/lzMenOqVlCKlF4P9?=
 =?Windows-1252?Q?Henl9jqVuuLjD6sJicVUUQOSA/aLCIO36DY=3D?=
Content-Type: multipart/alternative;
	boundary="_000_DU0PR08MB7921A4C96214BA4517FD1E39A68EADU0PR08MB7921eurp_"
MIME-Version: 1.0
X-OriginatorOrg: parlamentib.es
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DU0PR08MB7921.eurprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 220bcc29-ad83-4ea8-034f-08de52944a0a
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2026 11:09:58.3537
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: eb8f8b70-f944-47bc-a844-e35b86fd8b5f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 YRFGghiIzYel10FaULAAhKLl5XZdFkyvg13/Mb63dk/jfGSBDFgy3S1l5fluRTkJdiNrkyQF44VuVIoOf3cyTA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB10123
List-Id: <pgsql-admin.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-admin@lists.postgresql.org>
List-Owner: <mailto:pgsql-admin-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-admin>
Archived-At: 
 <https://www.postgresql.org/message-id/DU0PR08MB7921A4C96214BA4517FD1E39A68EA%40DU0PR08MB7921.eurprd08.prod.outlook.com>
Precedence: bulk

--_000_DU0PR08MB7921A4C96214BA4517FD1E39A68EADU0PR08MB7921eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

On 13/01/2026 08:19, Gabriel Guillem Barcel=F3 Soteras wrote:
Hi,
We have a healthy PostgreSQL 15 instance (installed from the official Postg=
res repository) running on Red Hat 9. It serves several databases for inter=
nal SMB applications. The environment is stable=97apps perform well, disk u=
sage 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 main=
tenance operations, or the last run was 30=96200 days ago. These databases =
have very few deletions, and many tables show no growth at all=97typical fo=
r 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=92re also monitoring table bloat, which is currently under 1%, suggestin=
g that manual intervention may not be necessary and that autovacuum is doin=
g its job when needed.
From: Paul Smith* <paul@pscs.co.uk>
Date: Tuesday, 13 January 2026 at 10:50
To: pgsql-admin@lists.postgresql.org <pgsql-admin@lists.postgresql.org>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instanc=
e


You would normally not need to do anything manually - autovacuum is suffici=
ent. The main times anything else may be needed is if you do a mass delete =
or update, in which case the autovacuum may not be updating "quick enough" =
or you may want to do a "vacuum full" to recover disk space.

What is your monitoring system looking at that is making it generate those =
warnings? You need to see what criteria it is using, and then decide whethe=
r those matter to you, or if they're false warnings that need adjusting som=
ehow.


Paul

------------------

From: Gabriel

CheckMK, as Anton case, monitors several metrics with a PostgreSQL integrat=
ion<https://checkmk.com/integrations> . In this case is last vacuum and ana=
lyse<https://checkmk.com/integrations/postgres_stats>. It generates a monit=
oring item with pre-populated thresholds.

You are not wrong at all. The lazy admin problem is that adjusting monitori=
ng system on per-table basis is very time consuming, compared with  a weekl=
y manual vacuum + analyze that makes 'no harm' out of business hours. I thi=
nk i will go the weekly vacumdb route, or I will have to deactivate VACUUM =
and ANALYSE monitoring items.

Thank you!

--_000_DU0PR08MB7921A4C96214BA4517FD1E39A68EADU0PR08MB7921eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body>
<div dir=3D"ltr" style=3D"margin-right: 80px; margin-left: 80px; font-famil=
y: Aptos; font-size: 12pt; color: black;">
On 13/01/2026 08:19, Gabriel Guillem Barcel=F3 Soteras wrote:</div>
<div id=3D"mail-editor-reference-message-container" style=3D"color: inherit=
; background-color: inherit;">
<blockquote>
<div dir=3D"ltr" class=3D"ms-outlook-mobile-reference-message skipProofing"=
 style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">
Hi,</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"fo=
nt-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb=
(0, 0, 0);">
We have a healthy PostgreSQL 15 instance (installed from the official Postg=
res repository) running on Red Hat 9. It serves several databases for inter=
nal SMB applications. The environment is stable=97apps perform well, disk u=
sage is fine, and the system is not
 under heavy load.</div>
<div dir=3D"ltr" class=3D"ms-outlook-mobile-reference-message skipProofing"=
 style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"fo=
nt-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb=
(0, 0, 0);">
After integrating PostgreSQL into our monitoring system, I noticed warnings=
 related to VACUUM and ANALYZE. Some tables have never undergone these main=
tenance operations, or the last run was 30=96200 days ago. These databases =
have very few deletions, and many
 tables show no growth at all=97typical for internal SMB apps.</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"fo=
nt-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb=
(0, 0, 0);">
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=
?</div>
<div dir=3D"ltr" class=3D"ms-outlook-mobile-reference-message skipProofing"=
 style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt=
; color: rgb(0, 0, 0);">
<br>
</div>
<div class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"fo=
nt-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb=
(0, 0, 0);">
We=92re also monitoring table bloat, which is currently under 1%, suggestin=
g that manual intervention may not be necessary and that autovacuum is doin=
g its job when needed.</div>
</blockquote>
</div>
<div dir=3D"ltr" class=3D"ms-outlook-mobile-reference-message skipProofing"=
 style=3D"margin-right: 40px; margin-left: 40px; font-family: Aptos; font-s=
ize: 12pt; color: black;">
<b>From: </b>Paul Smith* &lt;paul@pscs.co.uk&gt;<br>
<b>Date: </b>Tuesday, 13 January 2026 at 10:50<br>
<b>To: </b>pgsql-admin@lists.postgresql.org &lt;pgsql-admin@lists.postgresq=
l.org&gt;<br>
<b>Subject: </b>Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 =
Instance</div>
<div dir=3D"ltr" class=3D"ms-outlook-mobile-reference-message skipProofing"=
 style=3D"margin-right: 40px; margin-left: 40px; font-family: Aptos, Arial,=
 Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<p class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"marg=
in-right: 40px; margin-left: 40px;">
You would normally not need to do anything manually - autovacuum is suffici=
ent. The main times anything else may be needed is if you do a mass delete =
or update, in which case the autovacuum may not be updating &quot;quick eno=
ugh&quot; or you may want to do a &quot;vacuum
 full&quot; to recover disk space.&nbsp;</p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"marg=
in-right: 40px; margin-left: 40px;">
What is your monitoring system looking at that is making it generate those =
warnings? You need to see what criteria it is using, and then decide whethe=
r those matter to you, or if they're false warnings that need adjusting som=
ehow.</p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"marg=
in-right: 40px; margin-left: 40px;">
<br>
</p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing" style=3D"marg=
in-right: 40px; margin-left: 40px;">
Paul</p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing"><span style=
=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; colo=
r: rgb(0, 0, 0);">------------------</span></p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing"><span style=
=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; colo=
r: rgb(0, 0, 0);">From: Gabriel</span></p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing"><span style=
=3D"color: rgb(0, 0, 0);">CheckMK, as Anton case, monitors several metrics =
with a
</span><span style=3D"font-family: Aptos, Arial, Helvetica, sans-serif; fon=
t-size: 12pt; color: rgb(0, 0, 0);"><a href=3D"https://checkmk.com/integrat=
ions" data-outlook-id=3D"8c9b71dc-4212-4bfd-a69e-93c76b59e4fb" style=3D"mar=
gin-top: 0px; margin-bottom: 0px;">PostgreSQL
 integration</a></span><span style=3D"color: rgb(0, 0, 0);">&nbsp;. In this=
 case is <a href=3D"https://checkmk.com/integrations/postgres_stats" data-o=
utlook-id=3D"8f72c176-90a3-4fa7-99b3-eee77ed2ac52" style=3D"margin-top: 0px=
; margin-bottom: 0px;">
last vacuum and analyse</a>. It generates a monitoring item with pre-popula=
ted thresholds.</span></p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing"><span style=
=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; colo=
r: rgb(0, 0, 0);">You are not wrong at all. The<i>&nbsp;lazy admin&nbsp;pro=
blem
</i>is that adjusting monitoring system on per-table basis is very time con=
suming, compared with &nbsp;a weekly manual vacuum + analyze that makes 'no=
 harm' out of business hours. I think i will go the weekly vacumdb route, o=
r I will have to deactivate VACUUM and
 ANALYSE monitoring items.</span></p>
<p class=3D"ms-outlook-mobile-reference-message skipProofing"><span style=
=3D"font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; colo=
r: rgb(0, 0, 0);">Thank you!</span></p>
</body>
</html>

--_000_DU0PR08MB7921A4C96214BA4517FD1E39A68EADU0PR08MB7921eurp_--