Wait events monitoring future development

From: Ilya Kosmodemiansky <ilya(dot)kosmodemiansky(at)postgresql-consulting(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Wait events monitoring future development
Date: 2016-08-07 12:03:17
Message-ID: CAG95seUAQVj09KzLwU+z1B-GqdMqerzEkPFR3hn0q88XzMq-PA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

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)

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?

Best regards,
Ilya

--
Ilya Kosmodemiansky,

PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
ik(at)postgresql-consulting(dot)com

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-08-07 14:49:45 Re: Heap WARM Tuples - Design Draft
Previous Message Pavel Stehule 2016-08-07 09:15:22 patch: xmltable - proof concept