From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PG 16 draft release notes ready |
Date: | 2023-05-22 17:59:36 |
Message-ID: | 20230522175936.uprugkqv6aqkkmrt@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2023-05-21 22:46:58 -0400, Bruce Momjian wrote:
> > Looking through the release notes, I didn't see an entry for
> >
> > commit c6e0fe1f2a08505544c410f613839664eea9eb21
> > Author: David Rowley <drowley(at)postgresql(dot)org>
> > Date: 2022-08-29 17:15:00 +1200
> >
> > Improve performance of and reduce overheads of memory management
> >
> > even though I think that's one of the more impactful improvements. What was
> > the reason for leaving that out?
>
> If you read my previous email:
>
> > For the above two items, I mention items that would change user
> > like new features or changes that are significant enough that they would
> > change user behavior. For example, if a new join method increases
> > performance by 5x, that could change user behavior. Based on the quoted
> > numbers above, I didn't think "hash now faster" would be appropriate to
> > mention. Right?
I continue, as in past releases, to think that this is a bad policy. For
existing workloads performance improvements are commonly a more convincing
reason to upgrade than new features - they allow users to scale the workload
further, without needing application changes.
Of course there are performance improvement that are too miniscule to be worth
mentioning, but it's not a common case.
And here it's not just performance, but also memory usage, including steady
state memory usage.
> I can see this item as a big win, but I don't know how to describe it in a way
> that is helpful for the user to know.
In doubt the subject of the commit would just work IMO.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-05-22 17:59:59 | Re: Avoiding another needless ERROR during nbtree page deletion |
Previous Message | Andres Freund | 2023-05-22 17:52:54 | Re: walsender performance regression due to logical decoding on standby changes |