On Fri, Jun 12, 2020 at 6:11 PM Magnus Hagander <mag...@hagander.net> wrote: > > On Fri, Jun 12, 2020 at 10:23 AM Amit Kapila <amit.kapil...@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 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
