2016-08-07 21:03 GMT+09:00 Ilya Kosmodemiansky
> 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)
Thanks for your effort to make us move forward.
> 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?
Seems a good starting point. I'm interested in both, and I would like
with running (or writing) several tests.
Satoshi Nagayasu <sn...@uptime.jp>
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: