Re: vacuumdb changes for stats import/export
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, Frédéric Yhuel <frederic.yhuel@dalibo.com>, Nathan Bossart <nathandbossart@gmail.com>, John Naylor <johncnaylorls@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Jeff Davis <pgsql@j-davis.com>, jian he <jian.universality@gmail.com>, Matthias van de Meent <boekewurm+postgres@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Magnus Hagander <magnus@hagander.net>, Stephen Frost <sfrost@snowman.net>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, alvherre@alvh.no-ip.org
Date: 2025-07-26T19:38:09Z
Lists: pgsql-hackers
> > > > > > Statistics are transactional. Without this option specified are we > really > > removing them and commiting prior to computing and saving new ones? And > we are > > opposed to just changing this behavior and instead prefer to add an > option that > > at first glance seems like everyone should use? > > Yes, I thought it was transactional too, but the doc patch suggests is > isn't, so maybe I am wrong. > It is transactional, mostly. The attribute stats for the table being analyzed and all attribute stats for the dependent indexes that have at least one expression column, plus extended stats objects on that table, will be replaced in one atomic operation. The old stats were there, commit happens, now the new stats are there. The relation stats (pg_class) happen in-place, non-transactionally. So if you had an analyze that got canceled, and some of the relstats had been updated on the table or indexes, those would stay as-is. Having said all that, these are very nitpick details that may not need to be in our documentation. > > > "If not specified the system will analyze all statistics-capable objects > in > > alphabetical order. Specifying this option then limits the result to > only > > those objects that do not already have statistics.". That may not be how > the > > feature strictly behaves but that would seem to be all one would expect > it to > > do. > /me dons Hat of Pedantry (+2 against simple explanations) "Specifying this option then limits the result to only tables that are missing an attribute statistic, have an index that is missing an attribute statistic, or have an extended statistics object that is itself missing object statistics". /me removes hat "Specifying this option then limits the result to only those tables that do not already have complete statistics." The above phrase is asking the word "complete" to do a lot of heavy lifting, covering the dependent indexes and extended statistics objects. Specifying "table" makes it clear that any deficit in statistics results in the table getting analyzed, not just the single index or extended object.
Commits
-
doc: Adjust documentation for vacuumdb --missing-stats-only.
- ee924698d566 19 (unreleased) landed
- da103c7bc806 18.0 landed
-
Update guidance for running vacuumdb after pg_upgrade.
- c9d502eb6809 18.0 landed
-
vacuumdb: Add option for analyzing only relations missing stats.
- edba754f052e 18.0 landed
- 5f8eb25706b6 18.0 landed
-
vacuumdb: Teach vacuum_one_database() to reuse query results.
- 9c03c8d18721 18.0 landed