Add options to control whether VACUUM runs vac_update_datfrozenxid. VACUUM normally ends by running vac_update_datfrozenxid(), which requires a scan of pg_class. Therefore, if one attempts to vacuum a database one table at a time --- as vacuumdb has done since v12 --- we will spend O(N^2) time in vac_update_datfrozenxid(). That causes serious performance problems in databases with tens of thousands of tables, and indeed the effect is measurable with only a few hundred. To add insult to injury, only one process can run vac_update_datfrozenxid at the same time per DB, so this behavior largely defeats vacuumdb's -j option.
Hence, invent options SKIP_DATABASE_STATS and ONLY_DATABASE_STATS to allow applications to postpone vac_update_datfrozenxid() until the end of a series of VACUUM requests, and teach vacuumdb to use them. Per bug #17717 from Gunnar L. Sadly, this answer doesn't seem like something we'd consider back-patching, so the performance problem will remain in v12-v15. Tom Lane and Nathan Bossart Discussion: https://postgr.es/m/17717-6c50eb1c7d23a...@postgresql.org Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/a46a7011b27188af526047a111969f257aaf4db8 Modified Files -------------- doc/src/sgml/ref/vacuum.sgml | 37 +++++++++++++++++++++++++++++++ src/backend/commands/vacuum.c | 42 +++++++++++++++++++++++++++++++----- src/backend/postmaster/autovacuum.c | 9 ++++++-- src/bin/psql/tab-complete.c | 5 +++-- src/bin/scripts/t/100_vacuumdb.pl | 24 ++++++++++----------- src/bin/scripts/vacuumdb.c | 33 ++++++++++++++++++++++++++++ src/fe_utils/parallel_slot.c | 3 +++ src/include/commands/vacuum.h | 2 ++ src/test/regress/expected/vacuum.out | 6 ++++++ src/test/regress/sql/vacuum.sql | 7 ++++++ 10 files changed, 147 insertions(+), 21 deletions(-)