On Sat, Oct 30, 2021 at 12:21 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Oct 29, 2021 at 4:49 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Fri, Oct 29, 2021 at 10:54 AM Masahiko Sawada <sawada.m...@gmail.com> > > wrote: > > > > > > I'm not sure it's better to drop apply worker stats after resetting > > > skip xid (i.g., after skipping the transaction). Since the view is a > > > cumulative view and has last_error_time, I thought we can have the > > > apply worker stats until the subscription gets dropped. > > > > > > > Fair enough. So statistics can be removed either by vacuum or drop > > subscription. Also, if we go by this logic then there is no harm in > > retaining the stat entries for tablesync errors. Why have different > > behavior for apply and tablesync workers? > > > > I have another question in this regard. Currently, the reset function > > seems to be resetting only the first stat entry for a subscription. > > But can't we have multiple stat entries for a subscription considering > > the view's cumulative nature? > > > > Don't we want these stats to be dealt in the same way as tables and > functions as all the stats entries (subscription entries) are specific > to a particular database? If so, I think we should write/read these > to/from db specific stats file in the same way as we do for tables or > functions. I think in the current patch, it will unnecessarily read > and probably write subscription stats even when those are not > required.
Good point! So probably we should have PgStat_StatDBEntry have the hash table for subscription worker statistics, right? Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
