I've summarized Wait events monitoring discussion at Developer unconference
in Ottawa this year on wiki:


(Thanks to Alexander Korotkov for patiently pushing me to make this thing
finally done)

If you attended, fill free to point me out if I missed something, I will
put it on the wiki too.

Wait event monitoring looks ones again stuck on the way through community
approval in spite of huge progress done last year in that direction. The
importance of the topic is beyond discussion now, if you talk to any
PostgreSQL person about implementing such a tool in Postgres and if the
person does not get exited, probably you talk to a full-time PostgreSQL
developer;-) Obviously it needs a better design, both the user interface
and implementation, and perhaps this is why full-time developers are still

In order to move forward, imho we need at least some steps, whose steps can
be done in parallel

1. Further requirements need to be collected from DBAs.

   If you are a PostgreSQL DBA with Oracle experience and use perf for
troubleshooting Postgres - you are an ideal person to share your
experience, but everyone is welcome.

2. Further pg_wait_sampling performance testing needed and in different

   According to developers, overhead is small, but many people have doubts
that it can be much more significant for intensive workloads. Obviously, it
is not an easy task to test, because you need to put doubtfully
non-production ready code into mission-critical production for such tests.
   As a result it will be clear if this design should be abandoned  and we
need to think about less-invasive solutions or this design is acceptable.

Any thoughts?

Best regards,

Ilya Kosmodemiansky,

tel. +14084142500
cell. +4915144336040

Reply via email to