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. -- With Regards, Amit Kapila.
