Re: First draft of PG 19 release notes - Mailing list pgsql-hackers

On Mon, 20 Apr 2026 at 21:10, Bruce Momjian <bruce@momjian.us> wrote:
> In that thread from PG 17, I said:
>
> https://www.postgresql.org/message-id/ZlKaHOM8HYLy9nCY%40momjian.us
>
> > Well, let's start with a new section for PG 17 that lists these.  Is it
> > 20 items, 50, or 150?  I have no idea, but without the user-visible
> > filter, I am unable to determine what not-included performance features
> > are worthy of the release notes.

I imagine it's easier to prune away items that are not interesting
enough than to add ones that were skipped. Unless we get visibility of
ones that you skipped, it requires someone else to notice something is
missing (probably their own work), or it requires a complete parse of
all commits in the release.

> So, what is the filter I am supposed to use?  We even have a patch that,
> in aggregate, increases performance by 12-17%.  Is that under or over
> the threadshold to be included?  I have no idea.  And, even if we agree
> on a number, how do I handle commits with no numbers;  this commit
> didn't have a number.

That's going to be tricky to define. 2x performance increase in
something like initdb isn't going to be nearly as interesting to an
end user as making joins or aggregation go twice as fast. Maybe it
would be worth putting temporary tags on items that there are no
obvious performance numbers for to tell the author or committer that
you need proof, otherwise the item might disappear. For items that
might be more borderline worth adding, maybe those could also get
added and tagged to trigger some debate as to if they're worth keeping
around. In the end, we might see what it is you see with the bloated
release notes. You might find you get more agreement to remove things.
That's seldom requested with the current method. It seems reasonable
that not many people can sympathise with the "there are too many
items" problem, as by the time the notes go public, they're already
trimmed down to a manageable number. We might find that we all agree
on more things if the pruning is done more publicly.

> I can't follow rules that require me to consistently identify if a patch
> is a performance improvement, and if it is significant enough for the
> release notes.  If someone else can do that, please go ahead and stop
> blaming me for something I can't do.  I thought if it was easy, someone
> else since PG 17 would have either given me rules or done it.

I don't think anyone expects you to do anything that makes this job
harder than it already.  I expect a careful process change could make
this job easier for you.

> Can committers mention when they want something to be included in the
> release notes?  What we can do is to have all the hackers point out the
> missing items after I done creating the release notes, as messy as that
> is.

I wondered if the job could be made easier if we were to tag fixup
commits for commits that fix some recent feature commit. You could
pretty much ignore every single one of those for the release notes. If
that fixup information was more structured, it might also be very
interesting.

> One thing we can easily do is to add text to the release notes stating,
> "This release includes minor performance improvements that are too
> numerous to mention."

If the WIP draft contained the items of lesser importance, we might be
able to do some aggregation of those into something meaningful enough.
It might be much easier for people closer to the particular items to
aggregate them than it is for a single person to do it for all
commits. I'm aware that you already do quite a bit of this aggregation
already.

David