Date: Mon, 28 Jul 2025 13:34:11 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: "David G. Johnston" <david.g.johnston@gmail.com>
Cc: =?iso-8859-1?Q?Fr=E9d=E9ric?= 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>
Subject: Re: vacuumdb changes for stats import/export
Message-ID: <aIfCo9q_L-VHO624@nathan>
References: <Z9nnsPBlBzWxDuLi@nathan>
 <4b94ca16-7a6d-4581-b2aa-4ea79dbc082a@dalibo.com>
 <aITkuWC4Ww88GsFL@momjian.us>
 <CAKFQuwa2-oW__J7gAcVKgZnx658qBx9GknwL-wqX_0VvDc1EBQ@mail.gmail.com>
 <aIT9HMuQNIFfIlFH@momjian.us>
 <CADkLM=f9eYO_2f2LEf9a2zR_Zw9a4LtVAeqC_TdQEJdTuR-V+Q@mail.gmail.com>
 <8320fa2e-9200-46e2-b905-4a4d84707020@dalibo.com>
 <aIeNeo-zGgevViNc@nathan>
 <b527f417-b27c-43bb-8623-4c703fc0ad72@dalibo.com>
 <CAKFQuwYzgRbRBH6T+QZ=Cioy5rLB4mJDZUH2CjMebpFBDKuC_g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAKFQuwYzgRbRBH6T+QZ=Cioy5rLB4mJDZUH2CjMebpFBDKuC_g@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aIfCo9q_L-VHO624%40nathan>
Precedence: bulk

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