On 07/24/2018 12:06 PM, MyungKyu LIM wrote:
2018-07-23 16:53 (GMT+9), Michael Paquier wrote:
On Mon, Jul 23, 2018 at 04:04:42PM +0900, 임명규 wrote:
This proposal is about recording additional statistics of wait events.
I have comments about your patch. First, I don't think that you need to
count precisely the number of wait events triggered as usually when it
comes to analyzing a workload's bottleneck what counts is a periodic
*sampling* of events, patterns which can be fetched already from
pg_stat_activity and stored say in a different place.
Thanks for your feedback.
This proposal is not about *sampling*.
Accumulated statistics of wait events information is useful for solving
issue. It can measure accurate data.
Some case, sampling of events can not find the cause of issue. It lose detail
data.
For example, some throughput issue occur(ex : disk io), but each wait point
occurs only a few milliseconds.
In this case, it is highly likely that will not find the cause.
I think it's highly likely that it will find the cause. The idea of
sampling is that while you don't measure the timing directly, you can
infer it from the frequency of the wait events in the samples. So if you
see the backend reports a particular wait event in 75% of samples, it
probably spent 75% time waiting on it.
I'm not saying sampling is perfect and it certainly is less convenient
than what you propose.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
