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  ("imai.yoshikazu@fujitsu.com" <imai.yoshikazu@fujitsu.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Getting rid of some more lseek() calls
Следующее
От: Thomas Munro
Дата:
Сообщение: Re: WIP: WAL prefetch (another approach)