Re: First draft of PG 19 release notes

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.