Re: [Proposal] Add accumulated statistics - Mailing list pgsql-hackers

From Adrien NAYRAT
Subject Re: [Proposal] Add accumulated statistics
Date
Msg-id ebb2f596-304c-dc70-7eaa-a58aef39016c@anayrat.info
Whole thread Raw
In response to RE: [Proposal] Add accumulated statistics  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Responses RE: [Proposal] Add accumulated statistics  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
List pgsql-hackers
On 1/7/19 6:34 AM, Tsunakawa, Takayuki wrote:
> 1. Doesn't provide precise data
> Sampling could miss intermittent short waits, e.g., buffer content lock waits during checkpoints.  This might make it
difficultor impossible to solve transient performance problems, such as infrequent 100 millisecond response times while
thenormal response time is a few milliseconds.
 
> The proposed wait event collection doesn't miss anything.
> 
> 2. Overuses resources
> We may be able to shorten the sampling interval to 10 ms or even 1 ms to detect short periods of problems.  However,
thesampled data of active sessions become voluminous in memory and storage.  It would take longer to analyze those
samples. Also, the background sampling process prevents the CPU core from becoming idle to save power, which bgwriter
andwalwriter tries to avoid by hibernation.
 
> The proposed wait event collection just records what actually happened.  No waste.  Would it use many resources if
waitshappen frequently?  That leads to our motivation to reduce waits.
 

FIY, wait events have been added in PoWA by using pg_wait_sampling  
extension :  
https://rjuju.github.io/postgresql/2018/07/09/wait-events-support-for-powa.html

pg_wait_sampling sample the wait events in shared memory and PoWA store  
them.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: START/END line number for COPY FROM
Next
From: Jesper Pedersen
Date:
Subject: Re: pg_upgrade: Pass -j down to vacuumdb