On Tue, Mar 2, 2021 at 6:01 PM Peter Geoghegan <p...@bowt.ie> wrote: > 1. Any objections to the idea of teaching VACUUM ANALYZE to > distinguish between the cases where VACUUM ran and performed "real > index vacuuming", to make it more intelligent about overwriting > pg_class stats for indexes?
I think that a simpler approach would work better: When ANALYZE/do_analyze_rel() decides whether or not it should call vac_update_relstats() for each index, it should simply not care whether or not this is a VACUUM ANALYZE (as opposed to a simple ANALYZE). This is already what we do for the heap relation itself. Why shouldn't we do something similar for indexes? What do you think, Tom? Your bugfix commit b4b6923e03f from 2011 taught do_analyze_rel() to not care about whether VACUUM took place earlier in the same command -- though only in the case of the heap relation (not in the case of its indexes). That decision now seems a bit arbitrary to me. I should point out that this is the *opposite* of what we did from 2004 - 2011 (following Tom's 2004 commit f0c9397f808). During that time the policy was to not update pg_class.reltuples inside do_analyze_rel() when we knew that VACUUM ran. The policy was at least the same for indexes and the heap/table during this period, so it was consistent in that sense. However, I don't think that we should reintroduce that policy now. Doing so would be contrary to the API contract for index AMs established by Tom's 2006 commit e57345975cf -- that allowed amvacuumcleanup() to be a no-op when there was no ambulkdelete() call (it also taught hashvacuumcleanup() to do just that). To recap, our ultimate goal here is to make btvacuumcleanup() close to hashvacuumcleanup() -- it should be able to skip all cleanup when there was no btbulkdelete() call during the same VACUUM (nbtree page deletion still has cases that force us to do real work in the absence of a btbulkdelete() call for the VACUUM, but that remaining exception should be very rare). -- Peter Geoghegan
