Re: Removing vacuum_cleanup_index_scale_factor
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Tom Lane <tgl@sss.pgh.pa.us>
Date: 2021-03-08T21:00:56Z
Lists: pgsql-hackers
On Tue, Mar 2, 2021 at 6:01 PM Peter Geoghegan <pg@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
Commits
-
VACUUM ANALYZE: Always update pg_class.reltuples.
- 5f8727f5a679 14.0 landed
- 1fc5a57386d1 13.3 landed
-
Don't consider newly inserted tuples in nbtree VACUUM.
- 9f3665fbfc34 14.0 landed
- 9663d124466f 13.3 landed
-
Fix nbtree cleanup-only VACUUM stats inaccuracies.
- 48e1291342dd 14.0 cited
-
Disable recheck_on_update optimization to avoid crashes.
- 5d28c9bd73e2 12.0 cited
-
Fix VACUUM so that it always updates pg_class.reltuples/relpages.
- b4b6923e03f4 9.1.0 cited
-
Clean up API for ambulkdelete/amvacuumcleanup as per today's discussion.
- e57345975cf8 8.2.0 cited
-
First steps towards statistics on expressional (nee functional) indexes.
- f0c9397f8085 8.0.0 cited