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@xxxxxxxxxx> https://momjian.us EDB https://enterprisedb.com If only the physical world exists, free will is an illusion.
