Re: analyze-in-stages post upgrade questions

On Mon, Aug 18, 2025 at 3:40 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
>
> On Mon, 2025-08-18 at 11:38 +0900, Fujii Masao wrote:
> > Thanks! So I've updated the patch based on my earlier comments.
> > Unless there are objections, I'll commit the attached version to master only.
>
> I am fine with your patch.

Thanks for the review!


> One suggestion:
>
> > --- 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?


> 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.

Regards,

-- 
Fujii Masao