Re: Revive num_dead_tuples column of pg_stat_progress_vacuum

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Revive num_dead_tuples column of pg_stat_progress_vacuum
Дата
Msg-id 202406041535.pmyty3ci4pfd@alvherre.pgsql
обсуждение исходный текст
Ответ на Revive num_dead_tuples column of pg_stat_progress_vacuum  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список 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)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: meson "experimental"?
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Patch bug: Fix jsonpath .* on Arrays