On Tue, May 21, 2024 at 02:26:15PM -0400, Melanie Plageman wrote: > In Postgres development, we break larger projects into smaller ones > and then those smaller projects into multiple individual commits. Each > commit needs to stand alone and each subproject needs to have a > defensible benefit. One thing that is harder with performance-related > work than non-performance feature work is that there isn't always a > final "turn it on" commit. For example, let's say you are adding a new > view that tracks new stats of some kind. You do a bunch of refactoring > and small subprojects to make it possible to add the view. Then the > final commit that actually creates the view has obvious user value to > whoever is reading the log. For performance features, it doesn't > always work like this. > > For the vacuum WAL volume reduction, there were a bunch of smaller > projects throughout the last development year that I worked on that > were committed by different people and with different individual > benefits. Some changes caused vacuum to do less visibility checks (so > less CPU usage), some changed WAL format in a way that saves some > space, and some, like the commit you mention, make vacuum emit less > WAL. That commit by itself doesn't contain all of the user benefits of > the whole project. I couldn't think of a good place to list all of the > commits together that were part of the same project. Perhaps you could > argue that they were not in fact part of the same project and instead > were just small individual changes -- none of which are individually > worth including in the release notes.
I try and group them, but I am sure imperfectly. It is very true that infrastucture changes that enable later commits are often missed. -- Bruce Momjian <br...@momjian.us> https://momjian.us EDB https://enterprisedb.com Only you can decide what is important to you.
