Content-Type: multipart/alternative;
 boundary="------------0lBhZGl5ev3MAD3un0jKF6e4"
Message-ID: <81c12173-6da4-43e9-866a-00321a00415a@pscs.co.uk>
Date: Tue, 13 Jan 2026 09:39:23 +0000
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15
 Instance
Content-Language: en-GB
To: pgsql-admin@lists.postgresql.org
References: 
 <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
From: Paul Smith* <paul@pscs.co.uk>
In-Reply-To: 
 <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/81c12173-6da4-43e9-866a-00321a00415a%40pscs.co.uk>
Precedence: bulk

This is a multi-part message in MIME format.
--------------0lBhZGl5ev3MAD3un0jKF6e4
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

On 13/01/2026 08:19, Gabriel Guillem Barceló Soteras wrote:
> Hi,
> 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.
>
You would normally not need to do anything manually - autovacuum is 
sufficient. 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 whether those matter to you, or if they're false warnings that 
need adjusting somehow.


Paul

--------------0lBhZGl5ev3MAD3un0jKF6e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 13/01/2026 08:19, Gabriel Guillem
      Barceló Soteras wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        Hi,</div>
      <div
style="font-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 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.</div>
      <div dir="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div
style="font-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 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.</div>
      <div
style="font-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="ltr"
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        <br>
      </div>
      <div
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
        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.</div>
      <br>
    </blockquote>
    <p>You would normally not need to do anything manually - autovacuum
      is sufficient. 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. </p>
    <p>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 whether those matter to you, or if they're
      false warnings that need adjusting somehow.</p>
    <p><br>
    </p>
    <p>Paul</p>
  </body>
</html>

--------------0lBhZGl5ev3MAD3un0jKF6e4--