Horton

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

Melanie Plageman <melanieplageman@gmail.com>

View thread View on postgr.es
From: Melanie Plageman <melanieplageman@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Michael Paquier <michael@paquier.xyz>, Pg Hackers <pgsql-hackers@postgresql.org>, Andres Freund <andres@anarazel.de>
Date: 2024-01-16T16:28:46Z
Lists: pgsql-hackers 
On Tue, Jan 16, 2024 at 10:24 AM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Jan 15, 2024 at 4:03 PM Melanie Plageman
> <melanieplageman@gmail.com> wrote:
>
> > Perhaps it isn't important, but I find this wording confusing. You
> > mention lazy_scan_prune() and then mention that "the whole test is in
> > one place instead of spread out" -- which kind of makes it sound like
> > you are consolidating FSM updates for both the lazy_scan_noprune() and
> > lazy_scan_prune() cases. Perhaps simply flipping the order of the "since
> > the caller" and "moreover, this way" conjunctions would solve it. I
> > defer to your judgment.
>
> I rewrote the commit message a bit. See what you think of this version.

All LGTM.

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.