From: Bruce Momjian <bruce@momjian.us>
To: Franck Pachot <pg.franck@pachot.net>
Cc: Jeff Holt <jeff.holt@method-r.com>
Cc: pgsql-performance@lists.postgresql.org
Subject: Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
Date: Mon, 11 Oct 2021 15:04:41 -0400
Message-ID: <20211011190441.GA640@momjian.us> (raw)
In-Reply-To: <CAK6ito0Jm3ETnwP8OhGufoPJkNnLVNBwyb9J07Li=SsfvwkPvA@mail.gmail.com>
References: <CAMzkAgGAwh=vsUmtEOC-57GhbFo4eh_B7gJCWMqH4yR7hHJjgA@mail.gmail.com>
<CAK6ito0Jm3ETnwP8OhGufoPJkNnLVNBwyb9J07Li=SsfvwkPvA@mail.gmail.com>
On Mon, Oct 11, 2021 at 12:09:32AM +0200, Franck Pachot wrote:
> So the proposal is great, but there is also the risk of putting a large effort
> in describing the specification and maybe a patch, and that it is rejected. It
> should probably be discussed in the -hackers list (https://www.postgresql.org/
> list/pgsql-hackers/) first. And people will dislike it because it mentions
> Oracle. Or people will dislike it because they think this should be reserved to
> commercial forks. Or because it may introduce too much dependency on the OS.
> But some others will see the value of it. Discussions are good as long as they
> stay focused on the value of the community project. I don't have skills to
> contribute to the code, but will be happy to expose the need for this
> instrumentation (profiling time spent in database functions or system calls) as
> I have many examples for it.
I think there are three issues.
First, while the community is not _against_ something just because
Oracle has it, we are not in favor of it only becaues Oracle has it.
This means you have to make the case for its usefulness independent of
Oracle.
Second, while we clearly have successful wait event reporting in the
database server, it is less clear if we want event aggregation,
per-session summaries, and alerting in the database server, rather than
in an external project. Postgres has been successful in developing
backup, pooling, and failover tooling outside the database, so it is
possible the answer to this is to create an external project that does
this using the wait events in the server. If more database internal
support is needed for that, we can discuss that option with the
community.
Third, our normal work process is:
Desirability -> Design -> Implement -> Test -> Review -> Commit
Not going in this order often leads to backtracking or failure.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: bruce@momjian.us, pg.franck@pachot.net, jeff.holt@method-r.com, pgsql-performance@lists.postgresql.org
Subject: Re: Better, consistent instrumentation for postgreSQL using a similar API as Oracle
In-Reply-To: <20211011190441.GA640@momjian.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox