Feedback-ID: ia2694551:Fastmail
Date: Wed, 27 Nov 2024 19:05:51 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>,
	Nathan Bossart <nathandbossart@gmail.com>,
 Magnus Hagander <magnus@hagander.net>,
	Corey Huinker <corey.huinker@gmail.com>, Jeff Davis <pgsql@j-davis.com>,
	jian he <jian.universality@gmail.com>,
 Matthias van de Meent <boekewurm+postgres@gmail.com>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
 Peter Smith <smithpb2250@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Statistics Import and Export
Message-ID: <202411271805.vmm2bsgjqsm2@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1869337.1732725865@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/202411271805.vmm2bsgjqsm2%40alvherre.pgsql>
Precedence: bulk

On 2024-Nov-27, Tom Lane wrote:

> I do not like the idea of breaking existing upgrade scripts,
> especially not by requiring them to use a parameter that older
> vacuumdb versions will reject.  That makes it impossible to have a
> script that is version independent.  I really doubt that there is any
> usability improvement to be had here that's worth that.

I was only suggesting to break it because it was said upthread that that
was desirable behavior.

> How about causing "--analyze-in-stages" (as currently spelled) to
> be a no-op?  We could keep the behavior available under some other
> name.

I think making it a no-op isn't useful, because people who run the old
scripts will get the behavior we do not want: clobber the statistics and
recompute them, losing the benefit that this feature brings.

On 2024-Nov-27, Bruce Momjian wrote:

> Uh, I guess we could do that, but we should emit something like
> "--analyze-in-stages option ignored".

I think emitting a message is not useful.  It's quite possible that the
output of pg_upgrade will be redirected somewhere and this will go
unnoticed.


Maybe the most convenient for users is to keep "vacuumdb
--analyze-in-stages" doing exactly what we want to happen after
pg_upgrade, that is, in 18+, only recreate the missing stats.  This is
because of what Corey said about messaging: many users are not going to
get our message that they need to adapt their scripts, so they won't.
Breaking the script would convey that message pretty quickly, but you're
right that it's not very convenient.

For people that want to use the old behavior of recomputing _all_
statistics not just the missing ones, we could add a different switch,
or an (optional) option to --analyze-in-stages.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/