RE: Re: [Proposal] Add accumulated statistics for wait event
От | MyungKyu LIM |
---|---|
Тема | RE: Re: [Proposal] Add accumulated statistics for wait event |
Дата | |
Msg-id | 20180724101033epcms4p3da67d7bf66f4a75b0db65fc371ca2793@epcms4p3 обсуждение исходный текст |
Ответ на | Re: [Proposal] Add accumulated statistics for wait event (Alexander Korotkov <a.korotkov@postgrespro.ru>) |
Ответы |
RE: Re: [Proposal] Add accumulated statistics for wait event
|
Список | pgsql-hackers |
> On Mon, Jul 23, 2018 at 10:53 AM Michael Paquier <michael@paquier.xyz> wrote: >> What's the performance penalty? I am pretty sure that this is >> measurable as wait events are stored for a backend for each I/O >> operation as well, and you are calling a C routine within an inlined >> function which is designed to be light-weight, doing only a four-byte >> atomic operation. > Yes, the question is overhead of measuring durations of individual wait events. It has been proposed before, and therebeen heated debates about that (see threads [1-3]). It doesn't seem > to be a conclusion about this feature. The thing to be said for sure: > performance penalty heavily depends on OS/hardware/workload. In some cases overhead is negligible, but in other casesit appears to be huge. Thanks for good information. I agree. Performance penalty is exist. But wait stats are demandable and useful. In some cases, it is worth sacrificing performance and using it. So, what do you think about developing as extension? I have another concept proposal. 2. This feature can be implemented as extension if some hooks were provided in following functions, - pgstat_report_wait_start - pgstat_report_wait_end This feature can be turned on/off by on-line config when necessary. Best regards, MyungKyu, Lim
В списке pgsql-hackers по дате отправления: