public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alvaro Herrera <[email protected]>
To: Bruce Momjian <[email protected]>
Cc: Melanie Plageman <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: First draft of PG 17 release notes
Date: Wed, 15 May 2024 10:38:20 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
On 2024-May-14, Bruce Momjian wrote:
> On Tue, May 14, 2024 at 03:39:26PM -0400, Melanie Plageman wrote:
> > I think that we need to more clearly point out the implications of the
> > feature added by Sawada-san (and reviewed by John) in 667e65aac35497.
> > Vacuum no longer uses a fixed amount of memory for dead tuple TID
> > storage and it is not preallocated. This affects users as they may
> > want to change their configuration (and expectations).
> >
> > If you make that item more specific to their work, you should also
> > remove my name, as the work I did on vacuum this release was unrelated
> > to their work on dead tuple TID storage.
> >
> > The work Heikki and I did which culminated in 6dbb490261 mainly has
> > the impact of improving vacuum's performance (vacuum emits less WAL
> > and is more efficient). So you could argue for removing it from the
> > release notes if you are using the requirement that performance
> > improvements don't go in the release notes.
>
> 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 don't know what's the impact of the Plageman/Linnakangas work, but
since there are no user-visible consequences other than it being faster,
I agree it could be put more succintly, perhaps together as a sub-para
of the same item.
What about something like this?
<para>
Lift the 1 GB allocation limit for vacuum memory usage for dead
tuples, and make storage more compact and performant.
</para>
<para>
This can reduce the number of index passes that vacuum has to perform
for tables with many dead tuples, shortening vacuum times.
</para>
<para>
Also, the WAL traffic caused by vacuum has been made more compact.
</para>
> > However, one of the preliminary commits for this f83d70976 does
> > change WAL format. There are three WAL records which no longer exist
> > as separate records. Do users care about this?
I don't think so.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"You don't solve a bad join with SELECT DISTINCT" #CupsOfFail
https://twitter.com/connor_mc_d/status/1431240081726115845
view thread (146+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: First draft of PG 17 release notes
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox