Horton

Re: Emit fewer vacuum records by reaping removable tuples during pruning

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Michael Paquier <michael@paquier.xyz>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2024-01-25T02:26:12Z
Lists: pgsql-hackers 
On Wed, Jan 24, 2024 at 9:13 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I didn't incorporate it because I wasn't sure I understood the
> situation. I can imagine us skipping updating the FSM after
> lazy_scan_prune() because there are indexes on the relation and dead
> items on the page and we think we'll do a second pass. Later, we end
> up triggering a failsafe vacuum or, somehow, there are still too few
> TIDs for the second pass, so we update do_index_vacuuming to false.
> Then we wouldn't ever record this block's free space in the FSM. That
> seems fine (which is what the comment says). So, what does the last
> sentence mean? "Besides, we start recording..."

It means: when the failsafe kicks in, from that point on we won't do
any more heap vacuuming. Clearly any pages that still need to be
scanned at that point won't ever be processed by
lazy_vacuum_heap_rel(). So from that point on we should record the
free space in every scanned heap page in the "first heap pass" --
including pages that have LP_DEAD stubs that aren't going to be made
LP_UNUSED in the ongoing VACUUM.

-- 
Peter Geoghegan

Commits

  1. Combine FSM updates for prune and no-prune cases.

  2. Remove LVPagePruneState.

  3. Move VM update code from lazy_scan_heap() to lazy_scan_prune().

  4. Optimize vacuuming of relations with no indexes.

  5. Be more consistent about whether to update the FSM while vacuuming.

  6. Remove hastup from LVPagePruneState.

  7. Use scanned_pages to decide when to failsafe check.

  8. Simplify lazy_scan_heap's handling of scanned pages.

  9. While vacuuming a large table, update upper-level FSM data every so often.