On 13/01/2026 11:09, Gabriel Guillem Barceló Soteras wrote:
CheckMK, as Anton case, monitors several metrics with a PostgreSQL integration . In this case is last vacuum and analyse. 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
