RE: Failed transaction statistics to measure the logical replication progress

On Wednesday, December 15, 2021 9:52 PM vignesh C <vignesh21(at)gmail(dot)com> wrote:
> On Tue, Dec 14, 2021 at 7:58 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
> wrote:
> >
> > On Mon, Dec 13, 2021 at 5:48 PM osumi(dot)takamichi(at)fujitsu(dot)com
> > <osumi(dot)takamichi(at)fujitsu(dot)com> wrote:
> > >
> > > On Monday, December 13, 2021 6:19 PM Amit Kapila
> <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > > > On Tue, Dec 7, 2021 at 3:12 PM osumi(dot)takamichi(at)fujitsu(dot)com
> > > > <osumi(dot)takamichi(at)fujitsu(dot)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?
>
> We can remove the table sync workers transaction stats count to avoid
> confusion, take care of the documentation changes too accordingly.
Hi, apologies for my late reply.

Thank you, everyone for confirming the direction.
I'll follow the consensus of the community
and fix the patch, including other comments.
I'll treat only the stats for apply workers.

Best Regards,
Takamichi Osumi