Horton

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

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Melanie Plageman <melanieplageman@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2024-01-09T19:33:29Z
Lists: pgsql-hackers 
On Tue, Jan 9, 2024 at 2:23 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> Yes, I agree. I thought about it more, and I prefer updating the FSM
> and setting nonempty_pages into lazy_scan_[no]prune(). Originally, I
> had ordered the patch set with that first (before the patch to do
> immediate reaping), but there is no reason for it to be so. Using
> hastup can be done in a subsequent commit on top of the immediate
> reaping patch. I will post a new version of the immediate reaping
> patch which addresses your feedback. Then, separately, I will post a
> revised version of the lazy_scan_heap() refactoring patches.

I kind of liked it first, because I thought we could just do it and
get it out of the way, but if Andres doesn't agree with the idea, it
probably does make sense to push it later, as you say here.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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.