Content-Type: multipart/alternative;
 boundary="------------uEDMZyzXABEeF7UrAUm00j9j"
Message-ID: <05e54ad2-0d6b-49b0-834a-4107fee68c51@pscs.co.uk>
Date: Tue, 13 Jan 2026 11:28:37 +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>
 <81c12173-6da4-43e9-866a-00321a00415a@pscs.co.uk>
 <DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
From: Paul Smith* <paul@pscs.co.uk>
In-Reply-To: 
 <DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
Archived-At: 
 <https://www.postgresql.org/message-id/05e54ad2-0d6b-49b0-834a-4107fee68c51%40pscs.co.uk>
Precedence: bulk

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

On 13/01/2026 11:09, Gabriel Guillem Barceló Soteras wrote:
>
> CheckMK, as Anton case, monitors several metrics with a PostgreSQL 
> integration <https://checkmk.com/integrations> . In this case is last 
> vacuum and analyse <https://checkmk.com/integrations/postgres_stats>. 
> It generates a monitoring item with pre-populated thresholds.
>
> You are not wrong at all. The/ lazy admin problem /is that adjusting 
> monitoring system on per-table basis is very time consuming, compared 
> with  a weekly manual vacuum + analyze that makes 'no harm' out of 
> business hours. I think i will go the weekly vacumdb route, or I will 
> have to deactivate VACUUM and ANALYSE monitoring items.
>
OK

As you say, it does no harm, so you could do that, but I'd argue that 
it's also unnecessary. Personally, I'd disable those vacuum & analyze 
monitors. 'last autovacuum' and 'last autoanalyze' are a bit more useful 
monitoring stats than last manual vacuum/analyze, unless you have a 
company policy mandating otherwise.

Even then, I've just looked at one of our databases that's been running 
since 2019, and the 'last vacuum' AND 'last autovacuum' times are still 
null for a lot of the tables. It's simply unnecessary to vacuum those 
tables, or even analyze them, as they just hold a few rows of data that 
rarely change.

I'd say you're better monitoring other metrics, eg "n_mod_since_analyze" 
& "n_dead_tup", to see if vacuum/analyze is necessary for that table. 
That will show if autovacuum/analyze isn't keeping up with the job.

Paul

--------------uEDMZyzXABEeF7UrAUm00j9j
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 11:09, Gabriel Guillem
      Barceló Soteras wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com">
      <p class="ms-outlook-mobile-reference-message skipProofing"><span
          style="color: rgb(0, 0, 0);">CheckMK, as Anton case, monitors
          several metrics with a
        </span><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"><a
            href="https://checkmk.com/integrations"
            data-outlook-id="8c9b71dc-4212-4bfd-a69e-93c76b59e4fb"
            style="margin-top: 0px; margin-bottom: 0px;"
            moz-do-not-send="true">PostgreSQL integration</a></span><span
          style="color: rgb(0, 0, 0);"> . In this case is <a
            href="https://checkmk.com/integrations/postgres_stats"
            data-outlook-id="8f72c176-90a3-4fa7-99b3-eee77ed2ac52"
            style="margin-top: 0px; margin-bottom: 0px;"
            moz-do-not-send="true">
            last vacuum and analyse</a>. It generates a monitoring item
          with pre-populated thresholds.</span></p>
      <p class="ms-outlook-mobile-reference-message skipProofing"><span
style="font-family: Aptos, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">You
          are not wrong at all. The<i> lazy admin problem
          </i>is that adjusting monitoring system on per-table basis is
          very time consuming, compared with  a weekly manual vacuum +
          analyze that makes 'no harm' out of business hours. I think i
          will go the weekly vacumdb route, or I will have to deactivate
          VACUUM and ANALYSE monitoring items.</span></p>
    </blockquote>
    <p>OK</p>
    <p>As you say, it does no harm, so you could do that, but I'd argue
      that it's also unnecessary. Personally, I'd disable those vacuum
      &amp; analyze monitors. 'last autovacuum' and 'last autoanalyze'
      are a bit more useful monitoring stats than last manual
      vacuum/analyze, unless you have a company policy mandating
      otherwise.</p>
    <p>Even then, I've just looked at one of our databases that's been
      running since 2019, and the 'last vacuum' AND 'last autovacuum'
      times are still null for a lot of the tables. It's simply
      unnecessary to vacuum those tables, or even analyze them, as they
      just hold a few rows of data that rarely change.</p>
    <p>I'd say you're better monitoring other metrics, eg
      "n_mod_since_analyze" &amp; "n_dead_tup", to see if vacuum/analyze
      is necessary for that table. That will show if autovacuum/analyze
      isn't keeping up with the job.</p>
    <p>Paul</p>
  </body>
</html>

--------------uEDMZyzXABEeF7UrAUm00j9j--