Re: New IndexAM API controlling index vacuum strategies

On Tue, Mar 16, 2021 at 10:39 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Mar 15, 2021 at 11:04 AM Peter Geoghegan <pg(at)bowt(dot)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/