Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>, Melanie Plageman <melanieplageman@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Peter Geoghegan <pg@bowt.ie>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2024-01-09T19:35:36Z
Lists: pgsql-hackers 
Hi, 

On January 9, 2024 11:33:29 AM PST, Robert Haas <robertmhaas@gmail.com> wrote:
>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.


I don't have that strong feelings about it. If both of you think it looks good, go ahead... 


Andres 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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.