public inbox for [email protected]
help / color / mirror / Atom feedVACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
9+ messages / 6 participants
[nested] [flat]
* VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
@ 2026-01-13 08:19 =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 09:39 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
2026-01-13 17:26 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Laurenz Albe <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= @ 2026-01-13 08:19 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
Hi,
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.
Thanks for your insights!
-----
Gabriel
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
@ 2026-01-13 09:39 ` Paul Smith* <[email protected]>
2026-01-13 11:09 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Paul Smith* @ 2026-01-13 09:39 UTC (permalink / raw)
To: [email protected]
On 13/01/2026 08:19, Gabriel Guillem Barceló Soteras wrote:
> Hi,
> 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.
>
You would normally not need to do anything manually - autovacuum is
sufficient. The main times anything else may be needed is if you do a
mass delete or update, in which case the autovacuum may not be updating
"quick enough" or you may want to do a "vacuum full" to recover disk space.
What is your monitoring system looking at that is making it generate
those warnings? You need to see what criteria it is using, and then
decide whether those matter to you, or if they're false warnings that
need adjusting somehow.
Paul
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 09:39 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
@ 2026-01-13 11:09 ` =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 11:28 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= @ 2026-01-13 11:09 UTC (permalink / raw)
To: Paul Smith* <[email protected]>; +Cc: [email protected] <[email protected]>
On 13/01/2026 08:19, Gabriel Guillem Barceló Soteras wrote:
Hi,
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.
From: Paul Smith* <[email protected]>
Date: Tuesday, 13 January 2026 at 10:50
To: [email protected] <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
You would normally not need to do anything manually - autovacuum is sufficient. The main times anything else may be needed is if you do a mass delete or update, in which case the autovacuum may not be updating "quick enough" or you may want to do a "vacuum full" to recover disk space.
What is your monitoring system looking at that is making it generate those warnings? You need to see what criteria it is using, and then decide whether those matter to you, or if they're false warnings that need adjusting somehow.
Paul
------------------
From: Gabriel
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.
Thank you!
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 09:39 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
2026-01-13 11:09 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
@ 2026-01-13 11:28 ` Paul Smith* <[email protected]>
2026-01-13 14:52 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Ron Johnson <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Paul Smith* @ 2026-01-13 11:28 UTC (permalink / raw)
To: [email protected]
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 09:39 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
2026-01-13 11:09 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 11:28 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Paul Smith* <[email protected]>
@ 2026-01-13 14:52 ` Ron Johnson <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Ron Johnson @ 2026-01-13 14:52 UTC (permalink / raw)
To: Pgsql-admin <[email protected]>
On Tue, Jan 13, 2026 at 6:39 AM Paul Smith* <[email protected]> wrote:
> 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.
>
I created a view that joins pg_stat_user_tables to pg_class and then does:
select sut.table_name
, GREATEST(sut.last_vacuum, sut.last_autovacuum)::timestamp(3) without
time zone AS latest_vacuum
, GREATEST(sut.last_analyze, sut.last_autoanalyze)::timestamp(3)
without time zone AS latest_analyze
, sut.n_mod_since_analyze as mod_ana
, sut.n_dead_tup as dead_rows
, cl.reltuples::bigint as row_count
, case
when cl.reltuples > 0 then
(100.0*sut.n_mod_since_analyze/cl.reltuples)::decimal(6,2)
else null
end as mod_pct
, case
when cl.reltuples > 0 then
(100.0*sut.n_dead_tup/cl.reltuples)::decimal(6,2)
else null
end as dead_pct
That shows percentages as well as counts. Very helpful.
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.
>
And yet sometimes the course of least resistance is to make the metricians
happy. Fortunately, my metricians are reasonable enough to let me exclude
rows where (n_mod_since_analyze = 0 OR n_dead_tup = 0).
If OP's metricians are not reasonable, or there's too much hassle in
modifying the filter to exclude unmodified tables, then just "vacuumdb
--analyze -t foo -t bar -t ..." all tables that haven't been vacuumed or
analyzed in the last, for example, 28 days.
A bash+psql command can easily generate a "-t t1 -t t2 -t t3 ..." string
that you pass to vacuumdb.
> 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.
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
@ 2026-01-13 17:26 ` Laurenz Albe <[email protected]>
2026-01-13 17:30 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Rich Meyer <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Laurenz Albe @ 2026-01-13 17:26 UTC (permalink / raw)
To: Gabriel Guillem Barceló Soteras <[email protected]>; Pgsql-admin <[email protected]>
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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 17:26 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Laurenz Albe <[email protected]>
@ 2026-01-13 17:30 ` Rich Meyer <[email protected]>
2026-01-14 07:42 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Rich Meyer @ 2026-01-13 17:30 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; +Cc: Gabriel Guillem Barceló Soteras <[email protected]>; Pgsql-admin <[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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 17:26 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Laurenz Albe <[email protected]>
2026-01-13 17:30 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Rich Meyer <[email protected]>
@ 2026-01-14 07:42 ` =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-15 08:16 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Gabriel Guillem Barceló Soteras <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= @ 2026-01-14 07:42 UTC (permalink / raw)
To: [email protected] <[email protected]>; +Cc: Pgsql-admin <[email protected]>
https://www.pgadmin.org/support/list/
Go to PGLister Management link...
From: Rich Meyer <[email protected]>
Date: Tuesday, 13 January 2026 at 18:30
To: Laurenz Albe <[email protected]>
Cc: Gabriel Guillem Barceló Soteras <[email protected]>, Pgsql-admin <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
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]<mailto:[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
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 17:26 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Laurenz Albe <[email protected]>
2026-01-13 17:30 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance Rich Meyer <[email protected]>
2026-01-14 07:42 ` Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
@ 2026-01-15 08:16 ` Gabriel Guillem Barceló Soteras <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Gabriel Guillem Barceló Soteras @ 2026-01-15 08:16 UTC (permalink / raw)
To: ; +Cc: Pgsql-admin <[email protected]>
https://lists.postgresql.org/
From: Gabriel Guillem Barceló Soteras <[email protected]>
Date: Thursday, 15 January 2026 at 09:16
To: Ron Johnson <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
Oh god sorry, the site seemed postgresql.org like
From: Ron Johnson <[email protected]>
Date: Wednesday, 14 January 2026 at 16:03
To: Gabriel Guillem Barceló Soteras <[email protected]>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
lol no. That's for PG Admin IV, not the pgsql-admin list.
On Wed, Jan 14, 2026 at 2:42 AM Gabriel Guillem Barceló Soteras <[email protected]<mailto:[email protected]>> wrote:
https://www.pgadmin.org/support/list/
Go to PGLister Management link...
From: Rich Meyer <[email protected]<mailto:[email protected]>>
Date: Tuesday, 13 January 2026 at 18:30
To: Laurenz Albe <[email protected]<mailto:[email protected]>>
Cc: Gabriel Guillem Barceló Soteras <[email protected]<mailto:[email protected]>>, Pgsql-admin <[email protected]<mailto:[email protected]>>
Subject: Re: VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance
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]<mailto:[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
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2026-01-15 08:16 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-13 08:19 VACUUM/ANALYZE Strategy for Low-Activity PostgreSQL 15 Instance =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 09:39 ` Paul Smith* <[email protected]>
2026-01-13 11:09 ` =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-13 11:28 ` Paul Smith* <[email protected]>
2026-01-13 14:52 ` Ron Johnson <[email protected]>
2026-01-13 17:26 ` Laurenz Albe <[email protected]>
2026-01-13 17:30 ` Rich Meyer <[email protected]>
2026-01-14 07:42 ` =?Windows-1252?Q?Gabriel_Guillem_Barcel=F3_Soteras?= <[email protected]>
2026-01-15 08:16 ` Gabriel Guillem Barceló Soteras <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox