Re: Resetting spilled txn statistics in pg_stat_replication

On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <magnus(at)hagander(dot)net> wrote:
>
> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>
>
>
> The problem with "lifetime of a process" is that it's not predictable. A replication process might "bounce" for any reason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter a lot more. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a whole different sets of complexitites).
>

It is not clear to me what is a good way to display the stats for a
process that has exited or bounced due to whatever reason. OTOH, if
we just display per-slot stats, it is difficult to imagine how the
user can make any sense out of it or in other words how such stats can
be useful to users.

>
> > > The view
>>
>> > will have the following columns for example?
>> >
>> > * pid
>> > * slot_name
>> > * spill_txns
>> > * spill_count
>> > * spill_bytes
>> > * exec_count
>> >
>>
>> Yeah, these appear to be what I have in mind. Note that we can have
>> multiple entries of the same pid here because of slotname, there is
>> some value to display slotname but I am not completely sure if that is
>> a good idea but I am fine if you have a reason to include slotname?
>
>
> Well, it's a general view so you can always GROUP BY that away if you want at reading point?
>

Okay, that is a valid point.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com