Re: Release Note Changes

Simon Riggs wrote:
> On Fri, 2007-12-07 at 12:33 -0500, Bruce Momjian wrote:
> > Simon Riggs wrote:
> > > On Fri, 2007-11-30 at 09:49 +0000, Gregory Stark wrote:
> > > > "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> > > >
> > > > > If people understand there aren't 13 performance improvements there are
> > > > > at *least* 19+ that is a positive message to help people decide to
> > > > > upgrade.
> > > >
> > > > Frankly I think the release notes are already too long.
> > >
> > > So why do we have stuff in there that the users will never see?
>
> Thanks for your reply.
>
> > Which release note items?
>
> Most of the stuff in Source Code would fall into that category. I don't
> advocate removing those items, but I don't see the argument that space
> is so tight in the release notes that we have to remove important
> performance items but keep those.

I just looked at that section and see the need for each one. Which
items exactly?

> > > We already have a release summary, so why summarise *some* of the detail
> > > as well, but not all of it???
> > >
> > > I see no reason to diminish yours, Heikki's or my own contributions, all
> > > of which were in the area of performance, which people do care about.
> > > None of the ones I mentioned were trivial patches, nor were their
> > > effects small.
> >
> > I totally agree that we are unfair in how we give attribution in the
> > release notes.
>
> I do understand that the release notes are there to inform the user and
> not directly to give credit.
>
> Some important items have been removed from the release notes. It took
> me a whole month to notice, but I did eventually notice because I'm
> familiar with my own work, as well as that of people working on closely
> related items. I have, when I have been aware of them, pointed out
> patches produced by others that I thought were missing.
>
> > There is no weight given to patch difficulty and people
> > who produce user-invisible changes are much less likely to be mentioned
> > in the release notes.
>
> The reward system drives the outputs. If trivial feature additions are
> what we reward, then that's what we'll get. That's not important right
> now and discussing that is not why I started this thread.

Franky I don't think the release note mention is a significant part of
why people work on patches. If we remove names entirely, for example, I
don't think we would see any change in activity. The fact that this
issue hasn't come up since I started in 1996 confirms that.

> > I don't see any way to fix this that would not harm the release notes
> > themselves. As I mentioned in an earlier email the release notes are
> > designed to highlight user-visible changes in a user-understandable way.
> > The mentioning of people who wrote the patches is merely a side-effect
> > of that to give some credit, but it is a side-effect, not the main
> > reason we mention something in the release notes.
>
> Perhaps we are talking about different things. I'm discussing whether
> something is important and you seem to be imagining that I only want to
> see the phrase "(Simon)" lots of times. If that was the case, it would
> have been very simple to arrange, yet I seem to have elected the most
> difficult route to doing that. I could easily have hoovered up a few
> more trivial changes if that was my line of thinking. So it clearly
> wasn't.
>
> Maybe the importance of the patches that were removed wasn't clear
> enough, so let me explain my viewpoint. On another part of this thread I
> summarised the feedback from others to a list of features that were
> definitely user noticeable. The list was:
>
> - Merge Join performance has been substantially improved when low number
> of duplicate join keys exist on the outer side of the join (Simon, Greg)

Most users don't know if they are using mergejoins or not, nor are they
going to do anything differently now that the feature is in, so that is
why I don't see a need to mention it.

> - Large I/O reduction during recovery when full_page_writes = on
> (Heikki)

Again, a speedup, but not something that impacts people to behave
differently or see different output.

> - WAL file switch performance has been improved. Recovery startup now
> refers to the last checkpoint time, which may be anything up to the
> checkpoint_timeout interval before a database crash. (Simon, Tom)

The cput switch performance is the same issue as above. When you say
"recovery startup" are you talking about the log message?

> The last one seems important to me, but I can see that might be TMI for
> some people, though I feel we should document it somewhere. The other
> side of that is that many people know about those response time spikes
> and they will be very keen to know their cause was identified and
> removed.

True. We already mention some improvements in that area so I don't see
how mentioning something else that is kind of vague is going to help.

> Those items have resulted in important performance gains, not just a few
> percentage points. The first one can be 50% or more, the second one is
> 100% gain and the last one reduced response time spikes on busy systems
> by something like a second at switch time. I wouldn't dare to mention
> these things if the effects were small, but they are massive gains.

OK, we can add something about recovery being faster or something. We
could even tag it on to an existing item.

> > If people are concerned about the unfairness, and I understand that, the
> > best solution is not to add more items to the release notes to be more
> > fair, but to remove all names from release note items.
>
> That makes no sense, but it would benefit people that wrote fewer
> patches, I guess.

Yep, kind of illogical but it is fair.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +