Re: Failed transaction statistics to measure the logical replication progress

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Failed transaction statistics to measure the logical replication progress
Дата
Msg-id CAA4eK1+F9EndXZo2yu=_f6UWS1sk6Jiam-u6=hagqwopm9f+Dg@mail.gmail.com
обсуждение исходный текст
Ответ на RE: Failed transaction statistics to measure the logical replication progress  ("osumi.takamichi@fujitsu.com" <osumi.takamichi@fujitsu.com>)
Ответы RE: Failed transaction statistics to measure the logical replication progress  ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>)
Re: Failed transaction statistics to measure the logical replication progress  (Masahiko Sawada <sawada.mshk@gmail.com>)
Re: Failed transaction statistics to measure the logical replication progress  (vignesh C <vignesh21@gmail.com>)
Re: Failed transaction statistics to measure the logical replication progress  (Greg Nancarrow <gregn4422@gmail.com>)
Список pgsql-hackers
On Mon, Dec 13, 2021 at 5:48 PM osumi.takamichi@fujitsu.com
<osumi.takamichi@fujitsu.com> wrote:
>
> On Monday, December 13, 2021 6:19 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > On Tue, Dec 7, 2021 at 3:12 PM osumi.takamichi@fujitsu.com
> > <osumi.takamichi@fujitsu.com> wrote:
> >
> > Few questions and comments:
> Thank you for your comments !
>
> > ========================
> > 1.
> > The <structname>pg_stat_subscription_workers</structname> view will
> > contain
> >     one row per subscription worker on which errors have occurred, for workers
> >     applying logical replication changes and workers handling the initial data
> > -   copy of the subscribed tables.  The statistics entry is removed when the
> > -   corresponding subscription is dropped.
> > +   copy of the subscribed tables. Also, the row corresponding to the apply
> > +   worker shows all transaction statistics of both types of workers on the
> > +   subscription. The statistics entry is removed when the corresponding
> > +   subscription is dropped.
> >
> > Why did you choose to show stats for both types of workers in one row?
> This is because if we have hundreds or thousands of tables for table sync,
> we need to create many entries to cover them and store the entries for all tables.
>

If we fear a large number of entries for such workers then won't it be
better to show the value of these stats only for apply workers. I
think normally the table sync workers perform only copy operation or
maybe a fixed number of xacts, so, one might not be interested in the
transaction stats of these workers. I find merging only specific stats
of two different types of workers confusing.

What do others think about this?

-- 
With Regards,
Amit Kapila.



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

Предыдущее
От: "houzj.fnst@fujitsu.com"
Дата:
Сообщение: RE: parallel vacuum comments
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side