Re: Autovacuum and visibility maps
От | Ron Johnson |
---|---|
Тема | Re: Autovacuum and visibility maps |
Дата | |
Msg-id | CANzqJaC03VrGRJxU_c29YdX48byH1n71dGNRP7y21_dDjMJ5Ww@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Autovacuum and visibility maps (Adrian Klaver <adrian.klaver@aklaver.com>) |
Список | 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 по дате отправления: