Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Robert Treat <rob@xzilla.net>, Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2024-06-19T01:16:43Z
Lists: pgsql-hackers
On Tue, Jun 18, 2024 at 8:49 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > 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.

This isn't a small difference. It's actually a huge one in many cases:

https://www.postgresql.org/message-id/CAH2-WzkkGT2Gt4XauS5eQOQi4mVvL5X49hBTtWccC8DEqeNfKA@mail.gmail.com

Practically speaking they're just two different things, with hardly
any fixed relationship.

-- 
Peter Geoghegan



Commits

  1. Reintroduce dead tuple counter in pg_stat_progress_vacuum.

  2. Use TidStore for dead tuple TIDs storage during lazy vacuum.