Message-ID: <eec70e606527579077927e4facd04f978f588952.camel@j-davis.com>
Subject: Re: Statistics Import and Export
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>
Cc: Corey Huinker <corey.huinker@gmail.com>, Michael Paquier
 <michael@paquier.xyz>, jian he <jian.universality@gmail.com>, Nathan
 Bossart <nathandbossart@gmail.com>, Bruce Momjian <bruce@momjian.us>,
 Matthias van de Meent <boekewurm+postgres@gmail.com>, 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: Mon, 24 Feb 2025 10:42:40 -0800
In-Reply-To: <1457469.1740419458@sss.pgh.pa.us>
References: 
	<sdno5atrplq5b67vcx7x6fkzevwkzojd23izbguy2yma424wmp@siwbi3ijxdxs>
	 <x5yo5ly5u3dhzfaq3hrzeqhju3io5zmwk4yqrkge3ywcflffck@ghbbgsfv56yb>
	 <3670503.1740173078@sss.pgh.pa.us>
	 <blezfpeafycxlizyynwvwzh2vywmklhvfqudhicjrccu4raqpx@4ttfufowc2vo>
	 <3728741.1740178078@sss.pgh.pa.us>
	 <CADkLM=f0a43aTd88xW4xCFayEF25g-7hTrHX_WhV40HyocsUGg@mail.gmail.com>
	 <97b451228227c555be1a4f79c4a62ddec9a74f06.camel@j-davis.com>
	 <CADkLM=ckXu5wzSQZ3Y_fvAaL8rZ+upZdSecBLf5FCTMj7M6T-A@mail.gmail.com>
	 <b227c4fca29dfb893bb414ce6d84fc2377489ecc.camel@j-davis.com>
	 <CADkLM=dRMC6t8gp9GVf6y6E_r5EChQjMAAh_vPyih_zMiq0zvA@mail.gmail.com>
	 <y2d36zf6pl3n6ni6e4ctblu3a5iazi2dycknq53h2mjvp7lto4@hhww3h2qgdrw>
	 <1457469.1740419458@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.44.4-0ubuntu2 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/eec70e606527579077927e4facd04f978f588952.camel%40j-davis.com>
Precedence: bulk

On Mon, 2025-02-24 at 12:50 -0500, Tom Lane wrote:
> Also, while working on the attached, I couldn't help forming the
> opinion that we'd be better off to nuke pg_set_attribute_stats()
> from orbit and require people to use pg_restore_attribute_stats().

I had intended the pg_set variants to be useful for ad-hoc stats
hacking (e.g. for reproducing a plan or for testing the optimizer). For
those use cases, the following differences seem nice:

  1.=C2=A0named arguments are easier to write ad-hoc than lining up the
parameters in pairs
  2. elevel=3DERROR makes more sense than WARNING for that kind of use
case.
  3. for relation stats, we don't want in-place updates, because you
want ROLLBACK to work

Those seemed different enough from the restore case that another entry
point made sense to me.

> pg_set_attribute_stats() would be fine if we had a way to force
> people to call it with only named-argument notation, but we don't.
> So I'm afraid that its existence will encourage people to rely
> on a specific parameter order, and then they'll whine if we
> add/remove/reorder parameters, as indeed I had to do below.

That's a good point that I hadn't considered, so perhaps we can't solve
problem #1. The other two problems might be solvable though:

  * To avoid in-place updates I think we do need a separate function,
at least for relation stats (attribute stats never do in-place
updates). We could potentially have another name/value pair to choose,
but it's impossible to choose a reasonable default: if "inplace" is the
default, that means the user would need to opt-out of it for ROLLBACK
to work; if "mvcc" is the default, that means pg_dump would need to
choose "inplace", and I don't think pg_dump should be making those
kinds of decisions.

  * The elevel=3DERROR is not terribly important, so perhaps we can just
always do elevel=3DWARNING. If we did try to present it as an option,
then that presents the same problems as an "inplace" option.

So perhaps we can just have the pg_set variants set elevel=3DERROR and
inplace=3Dfalse, and otherwise be identical to the pg_restore variants?

Regards,
	Jeff Davis