On Thu, May 16, 2024 at 09:09:11AM -0400, Melanie Plageman wrote: > On Wed, May 15, 2024 at 11:48 PM Andres Freund <and...@anarazel.de> wrote: > > > > On 2024-05-15 10:38:20 +0200, Alvaro Herrera wrote: > > > I disagree with this. IMO the impact of the Sawada/Naylor change is > > > likely to be enormous for people with large tables and large numbers of > > > tuples to clean up (I know we've had a number of customers in this > > > situation, I can't imagine any Postgres service provider that doesn't). > > > The fact that maintenance_work_mem is no longer capped at 1GB is very > > > important and I think we should mention that explicitly in the release > > > notes, as setting it higher could make a big difference in vacuum run > > > times. > > > > +many. > > > > We're having this debate every release. I think the ongoing reticence to > > note > > performance improvements in the release notes is hurting Postgres. > > > > For one, performance improvements are one of the prime reason users > > upgrade. Without them being noted anywhere more dense than the commit log, > > it's very hard to figure out what improved for users. A halfway widely > > applicable performance improvement is far more impactful than many of the > > feature changes we do list in the release notes. > > The practical reason this matters to users is that they want to change > their configuration or expectations in response to performance > improvements. > > And also, as Jelte mentions upthread, describing performance > improvements made each release in Postgres makes it clear that we are > consistently improving it. > > > For another, it's also very frustrating for developers that focus on > > performance. The reticence to note their work, while noting other, far > > smaller, things in the release notes, pretty much tells us that our work > > isn't > > valued. > > +many
Please see the email I just posted. There are three goals we have to adjust for: 1. short release notes so they are readable 2. giving people credit for performance improvements 3. showing people Postgres cares about performance I would like to achieve 2 & 3 without harming #1. My experience is if I am reading a long document, and I get to a section where I start to wonder, "Why should I care about this?", I start to skim the rest of the document. I am particularly critical if I start to wonder, "Why does the author _think_ I should care about this?" becasue it feels like the author is writing for him/herself and not the audience. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.