Horton

Re: vacuumdb changes for stats import/export

Nathan Bossart <nathandbossart@gmail.com>

View thread View on postgr.es
From: Nathan Bossart <nathandbossart@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, Corey Huinker <corey.huinker@gmail.com>, Bruce Momjian <bruce@momjian.us>, 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" <alvherre@alvh.no-ip.org>
Date: 2025-07-28T18:34:11Z
Lists: pgsql-hackers 
On Mon, Jul 28, 2025 at 09:22:29AM -0700, David G. Johnston wrote:
> Makes sense.  This does beg the question - what happens if a column is left
> with a lower statistics target than what would be applied during an
> analyze, but one is present?  I don´t see where the statistics target is
> saved anywhere.  Can we start recording that piece of data and teach
> analyze in stages to just never go backwards - reporting any it had to skip
> to adhere to that rule.  Seems like a better policy than missing-only.

That would involve changing the behavior of an existing option, which has
thus far been strongly opposed [0], for what strikes me as a reasonably
uncommon situation.  Plus, --missing-stats-only may be useful in other
situations.

[0] https://postgr.es/m/Z6KKHX9PZkB19lAK%40nathan

-- 
nathan

Commits

  1. doc: Adjust documentation for vacuumdb --missing-stats-only.

  2. Update guidance for running vacuumdb after pg_upgrade.

  3. vacuumdb: Add option for analyzing only relations missing stats.

  4. vacuumdb: Teach vacuum_one_database() to reuse query results.