public inbox for [email protected]
help / color / mirror / Atom feedFrom: Rich Meyer <[email protected]>
To: Laurenz Albe <[email protected]>
Cc: Gabriel Guillem Barceló Soteras <[email protected]>
Cc: Pgsql-admin <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Date: Tue, 13 Jan 2026 12:30:24 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <DU0PR08MB79216D7A1EBC77E66899D508A68EA@DU0PR08MB7921.eurprd08.prod.outlook.com>
<[email protected]>
Hi, sorry about this but I cannot for the life of me unsubscribe from
these emails. Can anyone help?
---
Rich Meyer
Sevro Consulting
[email protected]
732-991-6249
On 2026-01-13 12:26 pm, Laurenz Albe wrote:
> On Tue, 2026-01-13 at 08:19 +0000, Gabriel Guillem Barceló Soteras
> wrote:
>
>> 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.
>
> I'd call this a false positive warning from the monitoring system, and
> there is nothing
> you have to do except to disable this test. It is perfectly healthy
> for a table with
> few updates and deletes to ve autovacuumed very rarely.
>
> What you should monitor is
>
> a) whether pg_stat_all.tables.n_dead_tup is much more than 0.2 *
> pg_class.reltuples + 50
> (that would indicate that autovacuum doesn't trigger, is too slow or
> cannot make any
> progress owing to long-running transactions)
>
> b) whether age(pg_class.relfrozenxid) exceeds 300 million
> (that would indicate a problem with anti-wraparound autovacuum)
>
> Yours,
> Laurenz Albe
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], [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