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

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Melanie Plageman <melanieplageman(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning
Date: 2024-01-12 20:01:59
Message-ID: CAH2-Wznty3E0Qn=sYneh4FqBQ3WuXhbPzbCnrt3aQzsB3Mvt0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 12, 2024 at 1:52 PM Melanie Plageman
<melanieplageman(at)gmail(dot)com> wrote:
> On Fri, Jan 12, 2024 at 1:07 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > What is "space_freed"? Isn't that something from your uncommitted patch?
>
> Yes, I was mixing the two together.

An understandable mistake.

> 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.

Right. As I said to Robert just now, I can now see that they're
slightly different conditions.

FWIW my brain was just ignoring " || !index_vacuuming". I dismissed it
as an edge-case, only relevant when the failsafe has kicked in. Which
it is. But that's still no reason to allow an inconsistency that we
can easily just avoid.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2024-01-12 20:04:19 Re: Emit fewer vacuum records by reaping removable tuples during pruning
Previous Message Tristan Partin 2024-01-12 19:57:22 Re: Extensible storage manager API - SMGR hook Redux