On Wed, 15 May 2024 at 20:38, Alvaro Herrera <alvhe...@alvh.no-ip.org> wrote: > > On 2024-May-14, Bruce Momjian wrote: > > I don't think users really care about these details, just that it is > > faster so they will not be surprised if there is a change. I was > > purposely vague to group multiple commits into the single item. By > > grouping them together, I got enough impact to warrant listing it. If > > you split it apart, it is harder to justify mentioning them. > > 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.
I very much agree with Alvaro here. IMO, this should be on the highlight feature list for v17. Prior to this, having to do multiple index scans because of filling maintenance_work_mem was a performance tragedy. If there were enough dead tuples to have filled maintenance_work_mem, then the indexes are large. Having to scan multiple large indexes multiple times isn't good use of I/O and CPU. As far as I understand it, this work means it'll be unlikely that a well-configured server will ever have to do multiple index passes. I don't think "enormous impact" is an exaggeration here. David
