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-6c50eb1c7d23a886@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(-)
