Re: 64-bit XIDs in deleted nbtree pages

On Tue, Feb 23, 2021 at 7:55 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Mon, Feb 22, 2021 at 4:21 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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/