Subject: Re: Better, consistent instrumentation for postgreSQL using a similar
 API as Oracle
To: pgsql-performance@lists.postgresql.org
References: 
 <CAMzkAgGAwh=vsUmtEOC-57GhbFo4eh_B7gJCWMqH4yR7hHJjgA@mail.gmail.com>
 <CAH2-Wzn-+=aYrMw4pHbV7yYVyRYskJkNLaV6HeHj94oyKJiRKA@mail.gmail.com>
 <efbd4d1a-48d5-99ac-549f-5e3f37812273@ardentperf.com>
 <4d9e6ac5-5b13-84fe-74b5-07421501318e@gmail.com>
 <20211008152132.GB31533@momjian.us>
From: Thomas Kellerer <shammat@gmx.net>
Message-ID: <738e0157-da3f-01aa-4e43-2b6e3c08ecca@gmx.net>
Date: Fri, 8 Oct 2021 17:28:37 +0200
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.21)
 Gecko/20090302 Thunderbird/2.0.0.21 Mnenhy/0.7.5.666
MIME-Version: 1.0
In-Reply-To: <20211008152132.GB31533@momjian.us>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/738e0157-da3f-01aa-4e43-2b6e3c08ecca%40gmx.net>
Precedence: bulk

Bruce Momjian schrieb am 08.10.2021 um 17:21:
> However, I also need to ask how the wait event information, whether
> tracing or sampling, can be useful for Postgres because that will drive
> the solution.

I guess everyone will use that information in a different way.

We typically use the AWR reports as a post-mortem analysis tool if
something goes wrong in our application (=customer specific projects)

E.g. if there was a slowdown "last monday" or "saving something took minutes yesterday morning",
then we usually request an AWR report from the time span in question. Quite frequently
this already reveals the culprit. If not, we ask them to poke in more detail into v$session_history.

So in our case it's not really used for active monitoring, but for
finding the root cause after the fact.

I don't know how representative this usage is though.

Thomas