Re: First draft of PG 17 release notes

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Subject: Re: First draft of PG 17 release notes
Date: 2024-05-15 11:17:50
Message-ID: CAApHDvrun6b+cAj6bgb6_1irnu+t7GU_uCdj1XvMQsPT0KngkQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 15 May 2024 at 20:38, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2024-05-15 11:24:42 Re: doc: some fixes for environment sections in ref pages
Previous Message Bertrand Drouvot 2024-05-15 10:31:02 Re: Avoid orphaned objects dependencies, take 3