Horton

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

Jim Nasby <jim.nasby@gmail.com>

View thread View on postgr.es
From: Jim Nasby <jim.nasby@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>, Peter Geoghegan <pg@bowt.ie>
Cc: Melanie Plageman <melanieplageman@gmail.com>, Michael Paquier <michael@paquier.xyz>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2024-01-16T21:28:32Z
Lists: pgsql-hackers 
On 1/12/24 12:45 PM, Robert Haas wrote:
> P.P.S. to everyone: Yikes, this logic is really confusing.

Having studied all this code several years ago when it was even simpler 
- it was *still* very hard to grok even back then. I *greatly 
appreciate* the effort that y'all are putting into increasing the 
clarity here.

BTW, back in the day the whole "no indexes" optimization was a really 
tiny amount of code... I think it amounted to 2 or 3 if statements. I 
haven't yet attempted to grok this patchset, but I'm definitely 
wondering how much it's worth continuing to optimize that case. Clearly 
it'd be very expensive to memoize dead tuples just to trawl that list a 
single time to clean the heap, but outside of that I'm not sure other 
optimazations are worth it given the amount of code 
complexity/duplication they seem to require - especially for code where 
correctness is so crucial.
-- 
Jim Nasby, Data Architect, Austin TX

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.