Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance

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