Re: Emit fewer vacuum records by reaping removable tuples during pruning
От | Robert Haas |
---|---|
Тема | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Дата | |
Msg-id | CA+TgmoZveZu=eCZ2fDwEy85mbc=d56Dqi3L2_mS3M3ymUJSaEA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Emit fewer vacuum records by reaping removable tuples during pruning (Melanie Plageman <melanieplageman@gmail.com>) |
Ответы |
Re: Emit fewer vacuum records by reaping removable tuples during pruning
|
Список | 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 по дате отправления: