Date: Tue, 19 Nov 2024 12:09:26 -0600
From: Nathan Bossart <nathandbossart@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: 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>,
	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
Subject: Re: Statistics Import and Export
Message-ID: <ZzzUVrJGmtxuxSv3@nathan>
References: 
 <CADkLM=edhVxHr5OGZHnUeoMkjFYNpE==puOKbB1E_7j1=QsbBw@mail.gmail.com>
 <CACJufxGmdV-9c7M_fs-2mGBMj1XiVqdOkW0NvibmpBJqedo1uQ@mail.gmail.com>
 <CADkLM=eErgzn7ECDpwFcptJKOk9SxZEk5Pot4d94eVTZsvj3gw@mail.gmail.com>
 <be7de51af6e969d501f69426c7137af6bde17fdc.camel@j-davis.com>
 <CADkLM=eSnbrOPfof8JeSZriFXnqpYcyRw8-WhL5nesbkduDdUQ@mail.gmail.com>
 <CADkLM=fR7TwH0cLREQkf5_=KLcOYVxJw0Km0i5MpaWeuDwVo6g@mail.gmail.com>
 <CADkLM=fBaHichB7oS=LZNfTpGHSOTO44OKR28BwNmwu+9PicOg@mail.gmail.com>
 <ZzuZzDMxe3ClqAgF@momjian.us>
 <CADkLM=cxNaU3O40Y5zGARJBWm-uAvb2hvgZxd=tOu-zTsrHpkQ@mail.gmail.com>
 <ZzvtC9NyukjgdX0e@momjian.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZzvtC9NyukjgdX0e@momjian.us>
Archived-At: <https://www.postgresql.org/message-id/ZzzUVrJGmtxuxSv3%40nathan>
Precedence: bulk

On Mon, Nov 18, 2024 at 08:42:35PM -0500, Bruce Momjian wrote:
> We can't design an API around who is going to be surprised.  We have to
> look at what the options say, what people would expect it to do, and
> what it does.  The reason "surprise" doesn't work in the long run is
> that while PG 18 users might be surprised, PG 20 users will be confused.

I think Bruce makes good points.  I'd add that even if we did nothing at
all for vacuumdb, folks who continued to use it wouldn't benefit from the
new changes, but they also shouldn't be harmed by it, either.

>> I, personally, would be fine if this only modified --analyze-in-stages, as it
>> already carries the warning:
> 
> Right, but I think we would need to rename the option to clarify what it
> does, e.g. --analyze-missing-in-stages.  If they use
> --analyze-in-stages, they will get an error, and will then need to
> reference the docs to see the new option wording, or we can suggest the
> new option in the error message.
> 
>> But others felt that --analyze-only should be in the mix as well.
> 
> Again, with those other people not saying so in this thread, I can't
> really comment on it --- I can only tell you what I have seen and others
> are going to have to explain why they want such dramatic changes.

I don't have a strong opinion here, but I suspect that if I was creating
vacuumdb from scratch, I'd have suggested a --missing-only flag that would
only work for --analyze-only/--analyze-in-stages.  That way, folks can
still regenerate statistics if they want, but we also have an answer for
folks who use pg_upgrade and have extended statistics.

-- 
nathan