Re: Autovacuum and visibility maps - Mailing list pgsql-general

From Ron Johnson
Subject Re: Autovacuum and visibility maps
Date
Msg-id CANzqJaC03VrGRJxU_c29YdX48byH1n71dGNRP7y21_dDjMJ5Ww@mail.gmail.com
Whole thread Raw
In response to Re: Autovacuum and visibility maps  (Adrian Klaver <adrian.klaver@aklaver.com>)
List pgsql-general
On Tue, Dec 3, 2024 at 11:57 AM Adrian Klaver <adrian.klaver@aklaver.com> wrote:
[snip] 

I have to believe it is due to this:

https://www.postgresql.org/docs/current/routine-vacuuming.html#VACUUM-FOR-SPACE-RECOVERY

"If you have a table whose entire contents are deleted on a periodic
basis, consider doing it with TRUNCATE rather than using DELETE followed
by VACUUM. TRUNCATE removes the entire content of the table immediately,
without requiring a subsequent VACUUM or VACUUM FULL to reclaim the
now-unused disk space. The disadvantage is that strict MVCC semantics
are violated."

Combined with this:

https://www.postgresql.org/docs/current/runtime-config-autovacuum.html#GUC-AUTOVACUUM-VACUUM-INSERT-THRESHOLD

"autovacuum_vacuum_threshold

Specifies the minimum number of updated or deleted tuples needed to
trigger a VACUUM in any one table. ...

"

I'm going to say the TRUNCATE itself does not trigger an autovacuum. I
would suggest throwing a manual VACUUM in the table population script.

Shouldn't autovacuum_vacuum_insert_threshold kick off an autovacuum if you're doing a lot of inserts?

--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

pgsql-general by date:

Previous
From: Sasmit Utkarsh
Date:
Subject: Best Practices for Managing Schema Changes Dynamically with libpq
Next
From: Ron Johnson
Date:
Subject: Re: Best Practices for Managing Schema Changes Dynamically with libpq