On Tue, Mar 16, 2021 at 10:39 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Mon, Mar 15, 2021 at 11:04 AM Peter Geoghegan <p...@bowt.ie> wrote: > > > > One consequence of my approach is that we now call > > lazy_cleanup_all_indexes(), even when we've skipped index vacuuming > > itself. We should at least "check-in" with the indexes IMV. To an > > index AM, this will be indistinguishable from a VACUUM that never had > > tuples for it to delete, and so never called ambulkdelete() before > > calling amvacuumcleanup(). This seems logical to me: why should there > > be any significant behavioral divergence between the case where there > > are 0 tuples to delete and the case where there is 1 tuple to delete? > > The extra work that we perform in amvacuumcleanup() (if any) should > > almost always be a no-op in nbtree following my recent refactoring > > work. More generally, if an index AM is doing too much during cleanup, > > and this becomes a bottleneck, then IMV that's a problem that needs to > > be fixed in the index AM. > > Aside from whether it's good or bad, strictly speaking, it could > change the index AM API contract. The documentation of > amvacuumcleanup() says: > > --- > stats is whatever the last ambulkdelete call returned, or NULL if > ambulkdelete was not called because no tuples needed to be deleted. > --- > > With this change, we could pass NULL to amvacuumcleanup even though > the index might have tuples needed to be deleted.
It seems there is no problem with that change at least in built-in index AMs. So +1 for this change. We would need to slightly update the doc accordingly. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
