Re: Design of pg_stat_subscription_workers vs pgstats

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Design of pg_stat_subscription_workers vs pgstats
Дата
Msg-id 20220221053453.lo6fzmji23ennvgj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: Design of pg_stat_subscription_workers vs pgstats  (Masahiko Sawada <sawada.mshk@gmail.com>)
Ответы Re: Design of pg_stat_subscription_workers vs pgstats  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
Hi,

On 2022-02-21 12:56:46 +0900, Masahiko Sawada wrote:
> > The patch you referenced [1] should just store the stats in the
> > pg_stat_subscription view, not pg_stat_subscription_workers.
> >
> > It *does* make sense to keep stats about the number of table syncs that failed
> > etc. But that should be a counter in pg_stat_subscription, not a row in
> > pg_stat_subscription_workers.
>
> We have discussed using pg_stat_subscription before but concluded it's
> not an appropriate place to store error information because it ends up
> keeping cumulative stats mixed with non-cumulative stats.

Well, as we've amply discussed, the non-cumulative stats shouldn't be in the
pgstat subsystem.


> To take a precedent, we used to store accumulative statistics such as
> spill_txns to pg_stat_replication, but then for the same reason we moved
> those statistics to the new stats view, pg_stat_replication_slot. New
> subscription statistics that we're introducing are cumulative statistics
> whereas pg_stat_subscription is a dynamic statistics view.

I'm happy to have cumulative subscriber stats somewhere in pgstats. But it
shouldn't be split by worker or relation, and it shouldn't contain
non-cumulative error information.

Greetings,

Andres Freund



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

Предыдущее
От: Noboru Saito
Дата:
Сообщение: Separate the result of \watch for each query execution (psql)
Следующее
От: Michael Paquier
Дата:
Сообщение: pg_stat_get_replication_slot and pg_stat_get_subscription_worker incorrectly marked as proretset