On Fri, 2021-10-01 at 15:06 -0500, Jeff Holt wrote: > TLDR; If I spend the time necessary to instrument the many functions that are the equivalent > of the Oracle counterparts, would anyone pull those changes and use them? > Specifically, for those who know Oracle, I'm talking about implementing: > 1. The portion of the ALTER SESSION that enables extended SQL trace > 2. Most of the DBMS_MONITOR and DBMS_APPLICATION_INFO packages > 3. Instrument the thousand or so functions that are the equivalent of those found in Oracle's V$EVENT_NAME > 4. Dynamic performance view V$DIAG_INFO > For the last 35 years, I've made my living helping people solve Oracle performance problems by looking at it > [...] > Now looking closely at postgreSQL, I see an opportunity to more quickly implement Oracle's current feature list. Anything that improves user experience in that respect is welcome, but consider that each database has different approaches to solve the same problems. Before you go to the length of implementing a lot of stuff, check in with the -hackers list and discuss your ideas. Please be a lot more specific than in this e-mail. While it is certainly fine to sketch your ambitios vision, focus on one specific thing you can imagine implementing and come up with a design for that. Note that "Oracle has it" is not a good enough reason for a PostgreSQL feature. We think we can do better than they do (at least in many respects). Also, don't assume that everyone on the -hackers list will be familiar with certain PostgreSQL features. One think that you should keep in mind is that Oracle has to provide different features in that area because they are not open source. In PostgreSQL, I can simply read the code or attach a debugger to a backend, and when it comes to profiling, "perf" works pretty well. So there is less need for these things. I don't want to discourage you, but contributing to PostgreSQL can be a lengthy and tedious process. On the upside, things that make it into core are usually fairly mature. Yours, Laurenz Albe
