On Tue, Jun 9, 2020 at 1:54 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Tue, Jun 9, 2020 at 9:12 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote:
>>
>> On Tue, 2 Jun 2020 at 18:34, Amit Kapila <amit.kapila16@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
othercolumn in it)
>
> However, I don't see how they *are* cumulative. They are only cumulative while the client is connected -- as soon as
itdisconnects 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
losedata.
>
> 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