Re: Revive num_dead_tuples column of pg_stat_progress_vacuum
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Andrey M. Borodin" <x4mmm@yandex-team.ru>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-06-14T00:35:18Z
Lists: pgsql-hackers
On Tue, Jun 11, 2024 at 10:38 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Fri, Jun 7, 2024 at 10:22 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > On Wed, Jun 5, 2024 at 7:19 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > > > > > > > > > > > > On 4 Jun 2024, at 00:26, Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > > > Thank you! Vacuum enhancement is a really good step forward, and this small change would help a lot of observability tools. > > > > > > > > > > On 4 Jun 2024, at 00:49, Peter Geoghegan <pg@bowt.ie> wrote: > > > > > > > > Can we rename this to num_dead_item_ids (or something similar) in > > > > passing? > > > > > > I do not insist, but many tools will have to adapt to this change [0,1]. However, most of tools will have to deal with removed max_dead_tuples anyway [2], so this is not that big problem. > > > > True, this incompatibility would not be a big problem. > > > > num_dead_item_ids seems good to me. I've updated the patch that > > incorporated the comment from Álvaro[1]. > > I'm going to push the v2 patch in a few days if there is no further comment. > 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? This patch reintroduces a previously-used column to pg_stat_progress_vacuum so it requires bumping the catversion. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Commits
-
Reintroduce dead tuple counter in pg_stat_progress_vacuum.
- f1affb67055c 17.0 landed
-
Use TidStore for dead tuple TIDs storage during lazy vacuum.
- 667e65aac354 17.0 cited