On Sat, Jun 15, 2024 at 8:47 PM Robert Treat <r...@xzilla.net> wrote: > > On Thu, Jun 13, 2024 at 9:22 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Fri, Jun 14, 2024 at 9:57 AM Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > > > On Fri, Jun 14, 2024 at 9:41 AM Michael Paquier <mich...@paquier.xyz> > > > wrote: > > > > On Thu, Jun 13, 2024 at 08:38:05PM -0400, Tom Lane wrote: > > > > > Masahiko Sawada <sawada.m...@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
