(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 sceptical.
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 environments.
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.
