Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Revive num_dead_tuples column of pg_stat_progress_vacuum
Date: 2024-06-04 15:35:04
Message-ID: 202406041535.pmyty3ci4pfd@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2024-Jun-03, Masahiko Sawada wrote:

> Commit 667e65aac3 changed num_dead_tuples and max_dead_tuples columns
> to dead_tuple_bytes and max_dead_tuple_bytes columns, respectively.
> But at PGConf.dev, I got feedback from multiple people that
> num_dead_tuples information still can provide meaning insights for
> users to understand the vacuum progress. One use case is to compare
> num_dead_tuples to pg_stat_all_tables.n_dead_tup column.

+1.

> @@ -2887,7 +2887,9 @@ dead_items_add(LVRelState *vacrel, BlockNumber blkno, OffsetNumber *offsets,
> TidStoreSetBlockOffsets(dead_items, blkno, offsets, num_offsets);
> vacrel->dead_items_info->num_items += num_offsets;
>
> - /* update the memory usage report */
> + /* update the progress information */
> + pgstat_progress_update_param(PROGRESS_VACUUM_NUM_DEAD_TUPLES,
> + vacrel->dead_items_info->num_items);
> pgstat_progress_update_param(PROGRESS_VACUUM_DEAD_TUPLE_BYTES,
> TidStoreMemoryUsage(dead_items));
> }

You could use pgstat_progress_update_multi_param here.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"The important things in the world are problems with society that we don't
understand at all. The machines will become more complicated but they won't
be more complicated than the societies that run them." (Freeman Dyson)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2024-06-04 16:07:00 Patch bug: Fix jsonpath .* on Arrays
Previous Message Dave Page 2024-06-04 15:28:22 Re: meson "experimental"?