Re: First draft of PG 19 release notes

Hi,

On 2026-04-20 12:12:07 -0400, Bruce Momjian wrote:
> 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.

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.

It's just that the answer to proposing listing certain performance
improvements shouldn't be that we don't include them as a matter of policy.

> It is only April 20. We still have time for someone to start from
> scratch and make a new version.

I don't see any need to start from scratch! That'd be foolish imo, it's a lot
of work to get to this point.

Greetings,

Andres Freund