Horton
Menu

Re: New IndexAM API controlling index vacuum strategies

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Noah Misch <noah@leadboat.com>
Date: 2021-03-16T15:38:29Z
Lists: pgsql-hackers 
On Tue, Mar 16, 2021 at 10:39 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Mon, Mar 15, 2021 at 11:04 AM Peter Geoghegan <pg@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/

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't truncate heap when VACUUM's failsafe is in effect.

  2. Teach VACUUM to bypass unnecessary index vacuuming.

  3. Add wraparound failsafe to VACUUM.

  4. Truncate line pointer array during VACUUM.

  5. Remove tupgone special case from vacuumlazy.c.

  6. Refactor lazy_scan_heap() loop.

  7. Propagate parallel VACUUM's buffer access strategy.

  8. Simplify state managed by VACUUM.

  9. Notice that heap page has dead items during VACUUM.

  10. Adjust lazy_scan_heap() accounting comments.

  11. Use full 64-bit XID for checking if a deleted GiST page is old enough.

  12. Fix some problems with VACUUM (INDEX_CLEANUP FALSE).