Re: [Proposal] Add accumulated statistics for wait event
От | Craig Ringer |
---|---|
Тема | Re: [Proposal] Add accumulated statistics for wait event |
Дата | |
Msg-id | CAMsr+YE1vSOgt4WO9-igpiaR=QSpm1piuWcPHUmr6ormB4cfUA@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: [Proposal] Add accumulated statistics for wait event ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>) |
Ответы |
RE: [Proposal] Add accumulated statistics for wait event
|
Список | pgsql-hackers |
On Wed, 12 Feb 2020 at 12:36, imai.yoshikazu@fujitsu.com <imai.yoshikazu@fujitsu.com> wrote: > It seems performance difference is big in case of read only tests. The reason is that write time is relatively longer thanthe > processing time of the logic I added in the patch. That's going to be a pretty difficult performance hit to justify. Can we buffer collected wait events locally and spit the buffer to the stats collector at convenient moments? We can use a limited buffer size with an overflow flag, so we degrade the results rather than falling over or forcing excessive stats reporting at inappropriate times. I suggest that this is also a good opportunity to add some more tracepoints to PostgreSQL. The wait events facilities are not very traceable right now. Exposing some better TRACE_POSTGRESQL_ tracepoints (SDTs) via probes.d would help users collect better information using external tools like perf, bpftrace and systemtap. That way we have a zero-overhead-when-unused option that can also be used to aggregate the information per-query, per-user, etc. (I really need to add a bunch more tracepoints to make this easier...) -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
В списке pgsql-hackers по дате отправления: