RE: Re: [Proposal] Add accumulated statistics for wait event

Поиск
Список
Период
Сортировка
От MyungKyu LIM
Тема RE: Re: [Proposal] Add accumulated statistics for wait event
Дата
Msg-id 20180724100623epcms4p717dd1338a876d8e1d2fdab2889b69690@epcms4p7
обсуждение исходный текст
Ответ на Re: [Proposal] Add accumulated statistics for wait event  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: [Proposal] Add accumulated statistics for wait event  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
 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.

> This is ugly and unmaintainable style.

I'm sorry. You're right.
Think as the PoC.
 
> What's the performance penalty?

I have same worries. I just tried pgbench several times.
Let me know what some good performance check method.

Best regards,
MyungKyu, Lim


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: Fix calculations on WAL recycling.
Следующее
От: MyungKyu LIM
Дата:
Сообщение: RE: Re: [Proposal] Add accumulated statistics for wait event