On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> 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.
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.
2. I don't think people will be motived to remove items, partly because
they might not want to upset anyone, and partly because they might
assume everyone else knows more. This could lead to the item count
doubling, not because we want all those items but because we can't trim,
and I would be embarrassed to be part of that and would probably stop
being involved.
3. My guess of what to add would be very poor. I can mostly guess new
workload performance items, but once it gets more granular than that, I
would guess poorly and don't want to field complaints about my poor
guesses.
I asked in the PG 17 thread for someone to create a list of missing
items, and that was mostly successful. Another approach would be for me
to create a document with the git detail of all commits I didn't include
--- that is easy to do since I have the commit hashes in the XML files,
and people can then look at that and tell me which commits need to be
added.
It is only April 20. We still have time for someone to start from
scratch and make a new version.
--
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.
