From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com>, "Zechman, Derek S" <Derek(dot)S(dot)Zechman(at)snapon(dot)com>, Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: analyze-in-stages post upgrade questions |
Date: | 2025-08-20 04:31:29 |
Message-ID: | CAHGQGwFS1uLe1U_edWDbxrCbqhrmqV1ag9WXWoFPuuK2YB3A8g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-hackers |
On Wed, Aug 20, 2025 at 12:16 AM Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> 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.
OK, so for now I've pushed the patch to master. Thanks!
Regards,
--
Fujii Masao
From | Date | Subject | |
---|---|---|---|
Next Message | Ertan Küçükoglu | 2025-08-20 04:47:43 | Domains vs data types |
Previous Message | David G. Johnston | 2025-08-19 20:28:35 | Re: vacuum analyze query performance - help me understand |
From | Date | Subject | |
---|---|---|---|
Next Message | Yugo Nagata | 2025-08-20 04:53:38 | Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only |
Previous Message | Yugo Nagata | 2025-08-20 04:30:12 | Re: Don't treat virtual generated columns as missing statistics in vacuumdb --missing-stats-only |