Re: Emit fewer vacuum records by reaping removable tuples during pruning - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Emit fewer vacuum records by reaping removable tuples during pruning
Date
Msg-id CA+TgmoY4Jyo+991COUWVpB-bTPbEKnMxf5pYfMg3oPywUOSnaQ@mail.gmail.com
Whole thread Raw
In response to Re: Emit fewer vacuum records by reaping removable tuples during pruning  (Melanie Plageman <melanieplageman@gmail.com>)
Responses Re: Emit fewer vacuum records by reaping removable tuples during pruning
List pgsql-hackers
On Fri, Jan 12, 2024 at 1:52 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> Yes, I was mixing the two together.
>
> I just want to make sure that we agree that, on master, when
> lazy_scan_prune() is called, the logic for whether or not to update
> the FSM after the first pass is:
>
> indexes == 0 || !has_lpdead_items || !index_vacuuming
>
> and when lazy_scan_noprune() is called, the logic for whether or not
> to update the FSM after the first pass is:
>
> indexes == 0 || !has_lpdead_items
>
> Those seem different to me.

This analysis seems correct to me, except that "when
lazy_scan_noprune() is called" should really say "when
lazy_scan_noprune() is called (and returns true)", because when it
returns false we fall through and call lazy_scan_prune() afterwards.

Here's a draft patch to clean up the inconsistency here. It also gets
rid of recordfreespace, because ISTM that recordfreespace is adding to
the confusion here rather than helping anything.

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

Attachment

pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Custom explain options
Next
From: Peter Geoghegan
Date:
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning