On Tue, Jun 9, 2020 at 1:54 PM Magnus Hagander <mag...@hagander.net> wrote: > > On Tue, Jun 9, 2020 at 9:12 AM Masahiko Sawada > <masahiko.saw...@2ndquadrant.com> wrote: >> >> On Tue, 2 Jun 2020 at 18:34, Amit Kapila <amit.kapil...@gmail.com> wrote: >> > >> > I see your point but I don't see a pressing need for such a function >> > for PG13. Basically, these counters will be populated when we have >> > large transactions in the system so not sure how much is the use case >> > for such a function. Note that we need to add additional column >> > stats_reset in pg_stat_replication view as well similar to what we >> > have in pg_stat_archiver and pg_stat_bgwriter. OTOH, I don't see any >> > big reason for not having such a function for PG14. >> >> Ok. I think the reset function is mostly for evaluations or rare >> cases. In either case, since it's not an urgent case we can postpone >> it to PG14 if necessary. > > > Reading through this thread, I agree that it's kind of weird to keep > cumulative stats mixed with non-cumulative stats. (it always irks me, for > example, that we have numbackends in pg_stat_database which behaves different > from every other column in it) > > However, I don't see how they *are* cumulative. They are only cumulative > while the client is connected -- as soon as it disconnects they go away. In > that regard, they're more like the pg_stat_progress_xyz views for example. > > Which makes it mostly useless for long-term tracking anyway. Because no > matter which way you snapshot it, you will lose data. > > ISTM the logical places to keep cumulative stats would be > pg_replication_slots? (Or go create a pg_stat_replication_slots?) That is, > that the logical grouping of these statistics for long-term is the > replication slot, not the walsender? >
I think I see one advantage of displaying these stats at slot level. Currently, we won't be able to see these stats when we use SQL Interface APIs (like pg_logical_get_slot_changes) to decode the WAL but if we display at slot level, then we should be able to see it. I would prefer to display it in pg_replication_slots just to avoid creating more views but OTOH, if a new view like pg_stat_replication_slots sounds better place for these stats then I am fine with it too. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
