Re: First draft of PG 17 release notes - Mailing list pgsql-hackers

From David Rowley
Subject Re: First draft of PG 17 release notes
Date
Msg-id CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com
Whole thread Raw
In response to Re: First draft of PG 17 release notes  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
On Wed, 15 May 2024 at 20:38, Alvaro Herrera <alvherre@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



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Avoid orphaned objects dependencies, take 3
Next
From: Peter Eisentraut
Date:
Subject: Re: doc: some fixes for environment sections in ref pages