Re: Emit fewer vacuum records by reaping removable tuples during pruning
От | Melanie Plageman |
---|---|
Тема | Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Дата | |
Msg-id | CAAKRu_bzobqdD=xSLDmDSMXB-7rkf9pa4KpYQC64AO6WvQONrA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Emit fewer vacuum records by reaping removable tuples during pruning (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Emit fewer vacuum records by reaping removable tuples during pruning
Re: Emit fewer vacuum records by reaping removable tuples during pruning |
Список | pgsql-hackers |
On Fri, Jan 12, 2024 at 1:07 PM Peter Geoghegan <pg@bowt.ie> wrote: > > On Fri, Jan 12, 2024 at 12:33 PM Melanie Plageman > <melanieplageman@gmail.com> wrote: > > So, I think this is the logic in master: > > > > Prune case, first pass > > > > ... > > - indexes > 0 && (!space_freed || !index_vacuuming) -> update FSM > > What is "space_freed"? Isn't that something from your uncommitted patch? Yes, I was mixing the two together. 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. - Melanie
В списке pgsql-hackers по дате отправления: