Message-ID: <46e2b1dac20cd7bf8f0c9af855afdfebefc0f9d0.camel@cybertec.at>
Subject: Re: analyze-in-stages post upgrade questions
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Mircea Cadariu <cadariu.mircea@gmail.com>, "Zechman, Derek S"
	 <Derek.S.Zechman@snapon.com>, Adrian Klaver <adrian.klaver@aklaver.com>, 
	pgsql-hackers@lists.postgresql.org
Date: Tue, 19 Aug 2025 17:16:12 +0200
In-Reply-To: <CAHGQGwHpA8nJfnX1Tk8CiVRUuZofACUFRHwk-8i=9yHYtmqiTw@mail.gmail.com>
References: 
	<CO1PR04MB8281387B9AD9DE30976966BBC045A@CO1PR04MB8281.namprd04.prod.outlook.com>
	 <6add2a9a-7cf2-4d1b-8f3e-2e26a7ebe883@aklaver.com>
	 <4d8122febd3007143504e4b6034b4253f7000761.camel@cybertec.at>
	 <PH0PR04MB82943D67CD179002714AA503C044A@PH0PR04MB8294.namprd04.prod.outlook.com>
	 <f2ebeef82fddaf8a8152383f8ff62e75f20aac3c.camel@cybertec.at>
	 <PH0PR04MB8294E796D6297D4E3BE4EFB6C049A@PH0PR04MB8294.namprd04.prod.outlook.com>
	 <08d943a83590308cbb9be594d80b4e19ca80e08e.camel@cybertec.at>
	 <2505eef1-b6aa-4518-baff-861a2e6a507b@gmail.com>
	 <b65126bf381d4b41f561afe691000b77ac7b8cc2.camel@cybertec.at>
	 <a018a729-9b18-444f-baed-be0d6d8ecb80@gmail.com>
	 <2c1f1834107045dfa8b32417771b56bab0cffc56.camel@cybertec.at>
	 <2cce9851-327a-4b1a-ab8e-531c2f92532b@gmail.com>
	 <CAHGQGwEvwpydO7hjnB51Q2zgS0ydv31X4HCFLNzMeqLr=poS8w@mail.gmail.com>
	 <9c9cb744-b8c7-4d75-acad-595b3faba187@gmail.com>
	 <CAHGQGwEj8PCk1OVveJ_F1sj_COrV95N-mfu_tLUn4gdcAM24kA@mail.gmail.com>
	 <9a93cffe79e2be1d9450a36e773a39dc456c241e.camel@cybertec.at>
	 <CAHGQGwGje3mv5sOmyCJ0NroNPF8938OYCOHMJZbegTekccZZ=g@mail.gmail.com>
	 <ad3adb5df84c50d78e9c1d118f55a06f753dd7dd.camel@cybertec.at>
	 <CAHGQGwHpA8nJfnX1Tk8CiVRUuZofACUFRHwk-8i=9yHYtmqiTw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/46e2b1dac20cd7bf8f0c9af855afdfebefc0f9d0.camel%40cybertec.at>
Precedence: bulk

On Tue, 2025-08-19 at 23:40 +0900, Fujii Masao wrote:
> > > --- a/doc/src/sgml/ref/vacuumdb.sgml
> > > +++ b/doc/src/sgml/ref/vacuumdb.sgml
> > > @@ -397,6 +397,15 @@ PostgreSQL documentation
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple table=
s can be vacuumed by writing multiple
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <option>-t</op=
tion> switches.
> > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </para>
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <para>
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If no tables are specifie=
d with the <option>--table</option> option,
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <application>vacuumdb</ap=
plication> will clean all regular tables
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and materialized views in=
 the connected database.
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If <option>--analyze-only=
</option> or
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <option>--analyze-in-stag=
es</option> is also specified,
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 it will analyze all regul=
ar tables, partitioned tables,
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and materialized views (b=
ut not foreign tables).
> > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </para>
> >=20
> > I suggest replacing "clean" with "process", since VACUUM does so much m=
ore than
> > clean up dead tuples.
>=20
> I see your point. However, since the vacuumdb docs already use "clean"
> in several places, I think it's better to keep using "clean" here
> for consistency. Thought?

Works for me; I didn't consider that.

> > Concerning backpatching, I voted against, but I suggest that this be ba=
ckpatched
> > to v18.=C2=A0 I don't feel very strongly about it though.
>=20
> As for back-patching, I failed to find a strong reason to apply this chan=
ge
> to v18 over the many other patches that could not be committed before
> the feature freeze... Of course if there's broad support for back-patchin=
g,
> we can certainly revisit it. But for now I'm thinking to commit the patch
> to master.

I don't have a strong reason either - my reasoning was that the change is s=
mall
and unlikely to introduce a bug, and that it would be nice to get more accu=
rate
statistics on partitioned tables after "pg_upgrade" a year earlier.

But I won't object if the patch is only in v19.

Yours,
Laurenz Albe