On Tue, May 21, 2024 at 12:27 PM Andres Freund <and...@anarazel.de> wrote: > > I agree the impact of performance improvements are often greater than > > the average release note item. However, if people expect Postgres to be > > faster, is it important for them to know _why_ it is faster? > > Yes, it very often is.
Is it important for them to even read the release notes? Bruce's arguments against listing performance items more often/with greater prominence could just as easily be applied to other types of features, in other areas. Performance is a feature (or a feature category) -- no better or worse than any other category of feature. > Performance improvements typically aren't "make > everything 3% faster", they're more "make this special thing 20% > faster". Without know what got faster, users don't know if > a) the upgrade will improve their production situation > b) they need to change something to take advantage of the improvement Another important category of performance improvement is "make the thing that was just unusable usable, for the first time ever". Sometimes the baseline is unreasonably slow, so an improvement effectively allows you as a user to do something that just wasn't possible on previous versions. Other times it's addressed at something that was very scary, like VACUUMs that need multiple rounds of index vacuuming. Multiple rounds of index vacuuming are just woefully, horribly inefficient, and are the single individual thing that can make things far worse. Even if you didn't technically have that problem before now, you did have the problem of having to worry about it. So the work in question has sanded-down this really nasty sharp edge. That's a substantial quality of life improvement for many users. In short, many individual performance improvements are best thought of as qualitative improvements, rather than quantitative improvements. It doesn't help that there is a kind of pressure to present them as quantitative improvements. For example, I was recently encouraged to present my own Postgres 17 B-Tree work internally using some kind of headline grabbing measure like "6x faster". That just seems silly to me. I can contrive a case where it's faster by an arbitrarily large amount. Much like how a selective index scan can be arbitrarily faster than a sequential scan. Again, a qualitative improvement. -- Peter Geoghegan