On Tue, Apr 21, 2026 at 11:52:37AM -0400, Andres Freund wrote: > On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote: > > So, these are not really rules, but a suggestion to just include more > > and we can trim. I see several problems with that: > > > > 1. Researching and writing each item is what takes the most time, so it > > could double my time to do this, which is fine if there were not other > > problems. > > FWIW, I think it's totally fine if you say that you don't want to do the work > to formulate performance improvement release note entries. It's a lot of work > to curate the release notes, it makes sense to split the work up.
When people complained about missing optimizer improvements, I was able to add them by referencing the plan changes they effect, with the assumption that they understand plan types. For lower-level performance improvements, it is nearly impossible for me to explain the items in a way that references something the reader will understand. Saying "widget X is faster" when the user has no idea what X is just isn't useful information for them, and I can't even explain widget X in a brief, user-relatable way. It is this fundamental issue that has prevented me from even trying. In summary, I was only able to do the optimizer additions by referencing plan types --- if I didn't assume users understand plan types, adding the optimizer issues would also have been impossible for me. I think David Rowley's idea of rolling up performance improvements into a single release note entry that is relatable is a great idea, but something I am incapable of doing without a lot of help. Giving a list of commits and git details might allow others to create text for such items. -- Bruce Momjian <[email protected]> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
