Re: Emit fewer vacuum records by reaping removable tuples during pruning - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Emit fewer vacuum records by reaping removable tuples during pruning
Date
Msg-id CAH2-Wzn1Mh-6=42GL_iMryqgmKJfYq+LLF5FoZus3W=WsHpUTw@mail.gmail.com
Whole thread Raw
In response to Re: Emit fewer vacuum records by reaping removable tuples during pruning  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Emit fewer vacuum records by reaping removable tuples during pruning
Re: Emit fewer vacuum records by reaping removable tuples during pruning
List pgsql-hackers
On Wed, Jan 17, 2024 at 4:25 PM Peter Geoghegan <pg@bowt.ie> wrote:
> I tend to suspect that VACUUM_FSM_EVERY_PAGES is fundamentally the
> wrong idea. If it's such a good idea then why not apply it all the
> time? That is, why not apply it independently of whether nindexes==0
> in the current VACUUM operation? (You know, just like with
> FAILSAFE_EVERY_PAGES.)

Actually, I suppose that we couldn't apply it independently of
nindexes==0. Then we'd call FreeSpaceMapVacuumRange() before our
second pass over the heap takes place for those LP_DEAD-containing
heap pages scanned since the last round of index/heap vacuuming took
place (or since VACUUM began). We need to make sure that the FSM has
the most recent possible information known to VACUUM, which would
break if we applied VACUUM_FSM_EVERY_PAGES rules when nindexes > 0.

Even still, the design of VACUUM_FSM_EVERY_PAGES seems questionable to me.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: On login trigger: take three
Next
From: Tom Lane
Date:
Subject: Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features)