Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYrz5-00060W-7Y for pgsql-performance@arkaria.postgresql.org; Fri, 08 Oct 2021 15:40:31 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mYrz3-0006cc-1T for pgsql-performance@arkaria.postgresql.org; Fri, 08 Oct 2021 15:40:29 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYrz2-0006cT-Oy for pgsql-performance@lists.postgresql.org; Fri, 08 Oct 2021 15:40:28 +0000 Received: from momjian.us ([72.94.173.45]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mYryz-0008D9-Ia for pgsql-performance@lists.postgresql.org; Fri, 08 Oct 2021 15:40:28 +0000 Received: from bruce by momjian.us with local (Exim 4.92) (envelope-from ) id 1mYryx-0002Ux-DO; Fri, 08 Oct 2021 11:40:23 -0400 Date: Fri, 8 Oct 2021 11:40:23 -0400 From: Bruce Momjian To: Thomas Kellerer Cc: pgsql-performance@lists.postgresql.org Subject: Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle Message-ID: <20211008154023.GC31533@momjian.us> References: <4d9e6ac5-5b13-84fe-74b5-07421501318e@gmail.com> <20211008152132.GB31533@momjian.us> <738e0157-da3f-01aa-4e43-2b6e3c08ecca@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <738e0157-da3f-01aa-4e43-2b6e3c08ecca@gmx.net> User-Agent: Mutt/1.10.1 (2018-07-13) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Oct 8, 2021 at 05:28:37PM +0200, Thomas Kellerer wrote: > 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. OK, that's a good usecase, and something that certainly would apply to Postgres. Don't you often need more than just wait events to find the cause, like system memory usage, total I/O, etc? -- Bruce Momjian https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.