Date: Tue, 21 Apr 2026 16:28:09 -0400
From: Bruce Momjian <bruce@momjian.us>
To: Andres Freund <andres@anarazel.de>
Cc: David Rowley <dgrowleyml@gmail.com>, David Geier <geidav.pg@gmail.com>,
	PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: First draft of PG 19 release notes
Message-ID: <aefd2Y5jNo4dcqJU@momjian.us>
References: <neyhppguim77qlq5h7hzchfsbgisipp7jxahztc3ekq3ev56l7@wj365ie267sq>
 <aeUWhHp2R_VO2zo-@momjian.us>
 <zdlyd6k6tto55tgn26wp5oeytmeipihn2ika4olm43kdgpxkhr@lsfb4zgo4oxq>
 <aeUgyfc4xKpXvxwT@momjian.us>
 <cueuimvdjht6pmpcsctwkx7f7tyha7qfuspuvhdpbkpmzclgcl@ly4ezmrcqp6i>
 <CAApHDvrZnPbbEr-PsNK1semY+rJKDGM2SS7MYNtta8a3Vb7Uzg@mail.gmail.com>
 <aeXtnlCj5_7SGroL@momjian.us>
 <CAApHDvoms82wjymG3KvHVRfYi68PXzYXRm-bR0tHgnATB+a4sQ@mail.gmail.com>
 <aeZQV8Yd_D6PkGBj@momjian.us>
 <vhjbilbej7vk2rge36zgppt26ya6lgrubgrwyxplvt3ybxvxpz@advb2fc3imyl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <vhjbilbej7vk2rge36zgppt26ya6lgrubgrwyxplvt3ybxvxpz@advb2fc3imyl>
Archived-At: 
 <https://www.postgresql.org/message-id/aefd2Y5jNo4dcqJU%40momjian.us>
Precedence: bulk

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.