forked frompostgres/postgres
- Notifications
You must be signed in to change notification settings - Fork6
Commit7ab96cf
committed
Refactor lazy_scan_heap() loop.
Add a lazy_scan_heap() subsidiary function that handles heap pruning andtuple freezing: lazy_scan_prune(). This is a great deal cleaner. Thecode that remains in lazy_scan_heap()'s per-block loop can now bethought of as code that either comes before or after the call tolazy_scan_prune(), which is now the clear focal point. This division isenforced by the way in which we now manage state. lazy_scan_prune()outputs state (using its own struct) that describes what to do with thepage following pruning and freezing (e.g., visibility map maintenance,recording free space in the FSM). It doesn't get passed any specialinstructional state from the preamble code, though.Also cleanly separate the logic used by a VACUUM with INDEX_CLEANUP=offfrom the logic used by single-heap-pass VACUUMs. The former case is nowstructured as the omission of index and heap vacuuming by a two passVACUUM. The latter case goes back to being used only when the tablehappens to have no indexes (just as it was before commita96c41f).This structure is much more natural, since the whole point ofINDEX_CLEANUP=off is to skip the index and heap vacuuming that wouldotherwise take place. The single-heap-pass case doesn't skip any usefulwork, though -- it just does heap pruning and heap vacuuming togetherwhen the table happens to have no indexes.Both of these changes are preparation for an upcoming patch thatgeneralizes the mechanism used by INDEX_CLEANUP=off. The later patchwill allow VACUUM to give up on index and heap vacuuming dynamically, asproblems emerge (e.g., with wraparound), so that an affected VACUUMoperation can finish up as soon as possible.Also fix a very old bug in single-pass VACUUM VERBOSE output. We werereporting the number of tuples deleted via pruning as a directsubstitute for reporting the number of LP_DEAD items removed in afunction that deals with the second pass over the heap. But thatdoesn't work at all -- they're two different things.To fix, start tracking the total number of LP_DEAD items encounteredduring pruning, and use that in the report instead. A single passVACUUM will always vacuum away whatever LP_DEAD items a heap page hasimmediately after it is pruned, so the total number of LP_DEAD itemsencountered during pruning equals the total number vacuumed-away.(They are _not_ equal in the INDEX_CLEANUP=off case, but that's okaybecause skipping index vacuuming is now a totally orthogonal concept toone-pass VACUUM.)Also stop reporting the count of LP_UNUSED items in VACUUM VERBOSEoutput. This makes the output of VACUUM VERBOSE more consistent withlog_autovacuum's output (because it never showed information aboutLP_UNUSED items). VACUUM VERBOSE reported LP_UNUSED items left behindby the last VACUUM, and LP_UNUSED items created via pruning HOT chainsduring the current VACUUM (it never included LP_UNUSED items left behindby the current VACUUM's second pass over the heap). This makes ituseless as an indicator of line pointer bloat, which must have been theoriginal intention. (Like the first VACUUM VERBOSE issue, this issue wasarguably an oversight in commit282d2a0, which added the heap-onlytuple optimization.)Finally, stop reporting empty_pages in VACUUM VERBOSE output, and startreporting pages_removed instead. This also makes the output of VACUUMVERBOSE more consistent with log_autovacuum's output (which does notshow empty_pages, but does show pages_removed). An empty page isn'tmeaningfully different to a page that is almost empty, or a page that isempty but for only a small number of remaining LP_UNUSED items.Author: Peter Geoghegan <pg@bowt.ie>Reviewed-By: Robert Haas <robertmhaas@gmail.com>Reviewed-By: Masahiko Sawada <sawada.mshk@gmail.com>Discussion:https://postgr.es/m/CAH2-WznneCXTzuFmcwx_EyRQgfsfJAAsu+CsqRFmFXCAar=nJw@mail.gmail.com1 parent091e22b commit7ab96cf
1 file changed
+633
-445
lines changed0 commit comments
Comments
(0)