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+TgmoZveZu=eCZ2fDwEy85mbc=d56Dqi3L2_mS3M3ymUJSaEA@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 Thu, Jan 25, 2024 at 11:19 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> Cool. I might add "successfully" or "fully" to "Either way, the page
> hasn't been processed yet"

I'm OK with that.

> > > I think it would be nice to clarify this comment. I think the "when
> > > there is little free space anyway" is referring to the case in
> > > lazy_vacuum() where we set do_index_vacuuming to false because "there
> > > are almost zero TIDs". I initially thought it was saying that in the
> > > failsafe vacuum case the pages whose free space we wouldn't record in
> > > the FSM have little free space anyway -- which I didn't get. But then
> > > I looked at where we set do_index_vacuuming to false.
> >
> > Oh... wow. That's kind of confusing; somehow I was thinking we were
> > talking about free space on the disk, rather than newly free space in
> > pages that could be added to the FSM.
>
> Perhaps I misunderstood. I interpreted it to refer to the bypass optimization.

I think you're probably correct. I just didn't realize what was meant.

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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: A performance issue with Memoize
Next
From: Robert Haas
Date:
Subject: Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock