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 <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Do not let urgent matters crowd out time for investment in the future.
