Re: Vacuuming TOAST after pg_restore - Mailing list pgsql-admin

From David G. Johnston
Subject Re: Vacuuming TOAST after pg_restore
Date
Msg-id CAKFQuwa6Hyy-vikVpcK8-ywOxyVG8CYRrVGdZVhqMkhSdbQ29A@mail.gmail.com
Whole thread Raw
In response to Re: Vacuuming TOAST after pg_restore  (Ron Johnson <ronljohnsonjr@gmail.com>)
List pgsql-admin
On Mon, Dec 18, 2023 at 4:14 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
On Mon, Dec 18, 2023 at 5:41 PM David G. Johnston <david.g.johnston@gmail.com> wrote:
On Mon, Dec 18, 2023 at 3:26 PM Ron Johnson <ronljohnsonjr@gmail.com> wrote:
PG 14.10

In the immediate post-pg_restore vaccumdb, can I skip immediate vacuuming of TOAST tables?

Heck, can I skip the immediate VACUUM, and only do an ANALYZE (then go back later and VACUUM)?

There has never been directions to perform an immediate vacuum post-restore.  A restore doesn't perform deletions.  Recovering from a physical backup will benefit from whatever vacuuming the cluster needed at the time it was backed up.
 
I'm sure I saw that it was recommended for the purpose of setting the FSM.


 "Visibility map bits are only set by vacuum, but are cleared by any data-modifying operations on a page."


I presume the VM refers to the main table only anyway so it gets updated regardless of whether TOAST is included in the vacuum.

Possibly you'd want to deal with tables with GIN indexes as well...though I'm unsure how those work exactly with bulk loading (or at all really...)

I don't know how the FSM would come into play.

David J.




pgsql-admin by date:

Previous
From: Ron Johnson
Date:
Subject: Re: Vacuuming TOAST after pg_restore
Next
From: Laurenz Albe
Date:
Subject: Re: Vacuuming TOAST after pg_restore