RE: New statistics for tuning WAL buffer size - Mailing list pgsql-hackers

From tsunakawa.takay@fujitsu.com
Subject RE: New statistics for tuning WAL buffer size
Date
Msg-id TYAPR01MB2990CB908A18CFD0970EE4AFFE300@TYAPR01MB2990.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: New statistics for tuning WAL buffer size  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: New statistics for tuning WAL buffer size
List pgsql-hackers
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
> Another reason that I mildly want to object to subdivided functions is
> I was annoyed that a stats view makes many individual calls to
> functions that internally share the same statistics entry.  That
> behavior required me to provide an entry-caching feature to my
> shared-memory statistics patch.

+1
The views for troubleshooting performance problems should be as light as possible.  IIRC, we saw  frequently searching
pg_stat_replicationconsume unexpectedly high CPU power, because it calls pg_stat_get_activity(null) to get all sessions
andjoin them with the walsenders.  At that time, we had hundreds of client sessions.  We expected pg_stat_replication
tobe very lightweight because it provides information about a few walsenders. 


Regards
Takayuki Tsunakawa






pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: __pg_log_level in anonynous enum should be initialized? (Was: pgsql: Change SHA2 implementation based on OpenSSL to use EVP digest ro)
Next
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: [Patch] Optimize dropping of relation buffers using dlist