On Thursday, September 30, 2021 8:13 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > On Thu, Sep 30, 2021 at 1:02 PM Osumi, Takamichi/大墨 昂道 > <osumi.takami...@fujitsu.com> wrote: > > > > On Thursday, September 30, 2021 1:15 PM Amit Kapila > <amit.kapil...@gmail.com> wrote: > > > On Thu, Sep 30, 2021 at 8:22 AM Hou, Zhijie/侯 志杰 > > > <houzj.f...@fujitsu.com> wrote: > > > > > > > > On Tues, Sep 28, 2021 6:05 PM Amit Kapila > > > > <amit.kapil...@gmail.com> > > > wrote: > > > > Adding a new view seems resonalble, but it will bring another > > > > subscription related view which might be too much. OTOH, I can see > > > > there are already some different views[1] including xact stat, > > > > maybe adding > > > another one is accepatble ? > > > These all views are related to untransmitted to the collector but > > > what we really need is a view similar to pg_stat_archiver or > > > pg_stat_bgwriter which gives information about background workers. > > > Now, the problem as I see is if we go that route then > > > pg_stat_subscription will no longer remain dynamic view and one > > > might consider that as a compatibility break. The other idea I have > > > shared is that we display these stats under the new view introduced > > > by Sawada-San's patch [1] and probably rename that view as > > > pg_stat_subscription_worker where all the stats (xact info and last > > > failure > > > information) about each worker will be displayed. > > Sorry, all the stats in pg_stat_subscription_worker view ? > > > > There was a discussion that > > the xact info should be displayed from pg_stat_subscription with > > existing stats in the same (which will be changed to persist), but > > when your above proposal comes true, the list of > > pg_stat_subscription_worker's columns will be something like below > > (when I list up major columns). > > > > - subid, subrelid and some other relation attributes required > > - 5 stats values moved from pg_stat_subscription > > received_lsn, last_msg_send_time, last_msg_receipt_time, > > latest_end_lsn, latest_end_time > > > > If we go with the view as pg_stat_subscription_worker, we don't need to move > the existing stats of pg_stat_subscription into it. Thank you for clarifying this point. I understand.
Best Regards, Takamichi Osumi