From: | Satoshi Nagayasu <snaga(at)uptime(dot)jp> |
---|---|
To: | ik(at)postgresql-consulting(dot)com |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Wait events monitoring future development |
Date: | 2016-08-09 03:37:15 |
Message-ID: | CAA8soze7r0oPs2pQNJdDr4Jjf=u_01CS5x2eG82m3xNP48fJng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2016-08-07 21:03 GMT+09:00 Ilya Kosmodemiansky
<ilya(dot)kosmodemiansky(at)postgresql-consulting(dot)com>:
> I've summarized Wait events monitoring discussion at Developer unconference
> in Ottawa this year on wiki:
>
> https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference/Wait_events_monitoring
>
> (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
> 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.
>
> Any thoughts?
Seems a good starting point. I'm interested in both, and I would like
to contribute
with running (or writing) several tests.
Regards,
--
Satoshi Nagayasu <snaga(at)uptime(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-08-09 03:47:38 | Re: Declarative partitioning |
Previous Message | Satoshi Nagayasu | 2016-08-09 03:17:07 | Re: Wait events monitoring future development |