On Sat, Jun 13, 2020 at 5:07 PM Fujii Masao <masao.fujii@oss.nttdata.com> wrote:
>
>
> On 2020/06/13 14:23, Amit Kapila wrote:
> > 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
anyreason, and it is normally not a problem. But if you suddenly lose your stats when you do that, it starts to matter
alot more. 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.
>
> If we allow users to set logical_decoding_work_mem per slot,
> maybe the users can tune it directly from the stats?
>
How will it behave when same slot is used from multiple sessions? I
think it will be difficult to make sense of the stats for slots unless
we also somehow see which process has lead to that stats and if we do
so then there won't be much difference w.r.t what we can do now?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
