On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <magnus@hagander.net> wrote:
>
> On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <amit.kapila16@gmail.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
lotmore. Especially when you don't know if it bounced. (Sure you can look at the backend_start time, but that adds a
wholedifferent 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