Re: analyze-in-stages post upgrade questions

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
> > >           Multiple tables can be vacuumed by writing multiple
> > >           <option>-t</option> switches.
> > >          </para>
> > > +       <para>
> > > +        If no tables are specified with the <option>--table</option> option,
> > > +        <application>vacuumdb</application> will clean all regular tables
> > > +        and materialized views in the connected database.
> > > +        If <option>--analyze-only</option> or
> > > +        <option>--analyze-in-stages</option> is also specified,
> > > +        it will analyze all regular tables, partitioned tables,
> > > +        and materialized views (but not foreign tables).
> > > +       </para>
> >
> > I suggest replacing "clean" with "process", since VACUUM does so much more than
> > clean up dead tuples.
>
> 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 backpatched
> > to v18.  I don't feel very strongly about it though.
>
> As for back-patching, I failed to find a strong reason to apply this change
> 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-patching,
> 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 small
and unlikely to introduce a bug, and that it would be nice to get more accurate
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