From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Melanie Plageman <melanieplageman(at)gmail(dot)com> |
Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, 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-25 17:25:46 |
Message-ID: | CA+TgmoZveZu=eCZ2fDwEy85mbc=d56Dqi3L2_mS3M3ymUJSaEA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jan 25, 2024 at 11:19 AM Melanie Plageman
<melanieplageman(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-01-25 17:28:19 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Tom Lane | 2024-01-25 17:22:59 | Re: A performance issue with Memoize |