On Tue, Feb 23, 2021 at 7:55 AM Peter Geoghegan <p...@bowt.ie> wrote: > > On Mon, Feb 22, 2021 at 4:21 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > The 0001 patch looks good to me. In the documentation, I think we need > > to update the following paragraph in the description of > > vacuum_cleanup_index_scale_factor: > > Good point. I think that the structure should make the page deletion > triggering condition have only secondary importance -- it is only > described at all to be complete and exhaustive. The > vacuum_cleanup_index_scale_factor-related threshold is all that users > will really care about in this area. > > The reasons for this are: it's pretty rare to have many page > deletions, but never again delete/non-hot update even one single > tuple. But when that happens, it's *much* rarer still to *also* have > inserts, that might actually benefit from recycling the deleted page. > So it's very narrow. > > I think that I'll add a "Note" box that talks about the page deletion > stuff, right at the end. It's actually kind of an awkward thing to > describe, and yet I think we still need to describe it.
Yeah, triggering btvacuumscan() by having many deleted index pages will become a rare case. Users are unlikely to experience it in practice. But it's still worth describing it. > > I also think that the existing documentation should clearly point out > that the vacuum_cleanup_index_scale_factor only gets considered when > there are no updates or deletes since the last VACUUM -- that seems > like an existing problem worth fixing now. It's way too unclear that > this setting only really concerns append-only tables. +1 Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
