Re: Resetting spilled txn statistics in pg_stat_replication - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Resetting spilled txn statistics in pg_stat_replication
Date
Msg-id 4fd3d009-55ad-6d87-daaf-beaede48cf82@oss.nttdata.com
Whole thread Raw
In response to Re: Resetting spilled txn statistics in pg_stat_replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Resetting spilled txn statistics in pg_stat_replication
List pgsql-hackers

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 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.

If we allow users to set logical_decoding_work_mem per slot,
maybe the users can tune it directly from the stats?

Regards,

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: Definitional issue: stddev_pop (and related) for 1 input
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade fails if vacuum_defer_cleanup_age > 0