public inbox for [email protected]  

help / color / mirror / Atom feed

From: Paul Smith* <[email protected]>
To: [email protected]
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Date: Tue, 13 Jan 2026 11:28:37 +0000
Message-ID: <[email protected]> (raw)
In-Reply-To: <DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
References: <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
	<[email protected]>
	<DU0PR08MB7921A4C96214BA4517FD1E39A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>

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

view thread (9+ messages)  latest in thread

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]
  Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
  In-Reply-To: <[email protected]>

* 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