Re: Wait events monitoring future development

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>

In response to

Browse pgsql-hackers by date

  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