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

From Peter Geoghegan
Subject Re: Emit fewer vacuum records by reaping removable tuples during pruning
Date
Msg-id CAH2-Wzm6BOh_L9-rUo=v8DTx-XU1+3FoDRZyRU+RwNx0f_fC2g@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>)
List pgsql-hackers
On Wed, Jan 24, 2024 at 9:13 PM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> I didn't incorporate it because I wasn't sure I understood the
> situation. I can imagine us skipping updating the FSM after
> lazy_scan_prune() because there are indexes on the relation and dead
> items on the page and we think we'll do a second pass. Later, we end
> up triggering a failsafe vacuum or, somehow, there are still too few
> TIDs for the second pass, so we update do_index_vacuuming to false.
> Then we wouldn't ever record this block's free space in the FSM. That
> seems fine (which is what the comment says). So, what does the last
> sentence mean? "Besides, we start recording..."

It means: when the failsafe kicks in, from that point on we won't do
any more heap vacuuming. Clearly any pages that still need to be
scanned at that point won't ever be processed by
lazy_vacuum_heap_rel(). So from that point on we should record the
free space in every scanned heap page in the "first heap pass" --
including pages that have LP_DEAD stubs that aren't going to be made
LP_UNUSED in the ongoing VACUUM.

--
Peter Geoghegan



pgsql-hackers by date:

Previous
From: torikoshia
Date:
Subject: Re: Add tuples_skipped to pg_stat_progress_copy
Next
From: jian he
Date:
Subject: Re: Make COPY format extendable: Extract COPY TO format implementations