Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

On Sat, Jun 15, 2024 at 8:47 PM Robert Treat <rob@xzilla.net> wrote:
>
> On Thu, Jun 13, 2024 at 9:22 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier <michael@paquier.xyz> wrote:
> > > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote:
> > > > > Masahiko Sawada <sawada.mshk@gmail.com> writes:
> > > > >> I was about to push the patch but let me confirm just in case: is it
> > > > >> okay to bump the catversion even after post-beta1?
> > > > >
> > > > > Yes, that happens somewhat routinely.
> > > >
> > > > Up to RC, even after beta2.  This happens routinely every year because
> > > > tweaks are always required for what got committed.  And that's OK to
> > > > do so now.
> > >
> > > Thank you both for confirmation. I'll push it shortly.
> > >
> >
> > Pushed. Thank you for giving feedback and reviewing the patch!
> >
>
> One minor side effect of this change is the original idea of comparing
> pg_stat_progress.num_dead_tuples to pg_stat_all_tables.n_dead_tup
> column becomes less obvious. I presume the release notes for
> pg_stat_progress_vacuum will be updated to also include this column
> name change as well, so maybe that's enough for folks to figure things
> out?

The release note has been updated, and I think it would help users
understand the change.

> At least I couldn't find anywhere in the docs where we have
> described the relationship between these columns before. Thoughts?

It would be a good idea to improve the documentation, but I think that
we cannot simply compare these two numbers since the numbers that
these fields count are slightly different. For instance,
pg_stat_all_tables.n_dead_tup includes the number of dead tuples that
are going to be HOT-pruned.

Regards,

-- 
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com