Message-ID: <8320fa2e-9200-46e2-b905-4a4d84707020@dalibo.com>
Date: Sun, 27 Jul 2025 12:46:44 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: vacuumdb changes for stats import/export
To: Corey Huinker <corey.huinker@gmail.com>, Bruce Momjian <bruce@momjian.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
 Nathan Bossart <nathandbossart@gmail.com>,
 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
References: <Z9BsEfqEmwkUetgz@nathan>
 <CANWCAZbiLHGeAZPYg6G6eT6MmCXM7CuYBEj3WhWw76e_HQejDA@mail.gmail.com>
 <Z9HhrtaZyFgMvJsM@nathan> <Z9R9-mFbxukqKmg4@nathan> <Z9jXuyymBSVDw9pv@nathan>
 <CADkLM=ek625v06WeeOpUNjGnCqyD8pH_0iYcCpg57KP3A8D9qg@mail.gmail.com>
 <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>
From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= <frederic.yhuel@dalibo.com>
Content-Language: fr, en-US
Autocrypt: addr=frederic.yhuel@dalibo.com; keydata=
 xjMEXn3bgxYJKwYBBAHaRw8BAQdA6tX5FT/n5ztMWIoBdl6k5avvu65fv6ryfVzIx/aH3V3N
 JEYuIFlodWVsIDxmcmVkZXJpYy55aHVlbEBkYWxpYm8uY29tPsKWBBMWCAA+FiEEi7OTyf6H
 ePS+C6n11XGWhN8zGNUFAmZDVJ8CGwMFCQtfi90FCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA
 CgkQ1XGWhN8zGNV65gEA6o+UrebFjn2CIAOYwP3CiiJugiM5TMH9yJyehQua5ZoA/2ChxiVn
 8OUaAw/ErxJmQi1mSN0tNZBL/KhkUPBDUDQNzjgEXn3bgxIKKwYBBAGXVQEFAQEHQCuh5cLQ
 AtEBXHa2Fmtp0kduBu7msM7qO/gaEcdjFUdiAwEIB8J+BBgWCAAmAhsMFiEEi7OTyf6HePS+
 C6n11XGWhN8zGNUFAmZDVJ8FCQtfi90ACgkQ1XGWhN8zGNWOOAEArSqePBqfd4Kx4ulACaWO
 6fM+XSDfUlBAQXx9rU6DR4MBALwozl9g91tRysim6lKxggvBfp/PvbpTZNrxYLWB2fYP
In-Reply-To: 
 <CADkLM=f9eYO_2f2LEf9a2zR_Zw9a4LtVAeqC_TdQEJdTuR-V+Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/8320fa2e-9200-46e2-b905-4a4d84707020%40dalibo.com>
Precedence: bulk


On 7/26/25 21:38, Corey Huinker wrote:
>=20
>=20
> It is transactional, mostly.
>=20
> The attribute stats for the table being analyzed and all attribute stat=
s=20
> for the dependent indexes that have at least one expression column, plu=
s=20
> extended stats objects on that table, will be replaced in one atomic=20
> operation. The old stats were there,=C2=A0commit happens, now the new s=
tats=20
> are there.
>=20
> The relation stats (pg_class) happen in-place, non-transactionally. So=20
> if you had an analyze that got canceled, and some of the relstats had=20
> been updated on the table or indexes, those would stay as-is.
>=20

Then it seems very unlikely that the query optimizer's choices become=20
transiently worse because of that, doesn't it? and this shouldn't be=20
used to justify this option, IMHO.

How about this? "This option is primarily intended to be used in=20
post-upgrade scripts to quickly generate minimal optimizer statistics"

> Having said all that, these are very nitpick details that may not need=20
> to be in our documentation.
>=20

+1

I've always supposed that the statistics were completely transactional,=20
I think most users do, and the difference with reality seems small enough=
.

>=20
>=20
>=20
> /me dons Hat of Pedantry=C2=A0(+2 against simple explanations)
>=20
> "Specifying this option then limits the result to only tables that are=20
> missing an attribute statistic, have an index that is missing an=20
> attribute statistic, or have an extended statistics object that is=20
> itself missing object statistics".
>=20
> /me removes hat
>=20
> "Specifying this option then limits the result to only those tables tha=
t=20
> do not already have complete statistics."
>=20
> The above phrase is asking the word "complete" to do a lot of heavy=20
> lifting, covering the dependent indexes and extended statistics objects=
.=20
> Specifying "table" makes it clear that any deficit in statistics result=
s=20
> in the table getting analyzed, not just the single index or extended ob=
ject.

FWIW I much prefer the last, simple phrase.