Re: Release Note Changes

Simon Riggs wrote:

[ Sorry for my delay in replying to this.]

> Few proposals
>
> - Can we say "smoothed" rather than "distributed" checkpoints?
> "Smoothed checkpoints greatly reduce checkpoint I/O spikes"

Agreed. Changed.

> - Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs
> change to
> "Heap-Only Tuples (HOT) improve performance of frequent UPDATEs"

I used the original text because it tries to explain _how_ HOT improves
performance. The item that has the descriptive text explains how the
space reuse works. A generic "improve performance" doesn't seem like an
improvement.

> I also notice that two performance features have disappeared from the
> release notes. (Presumably they have been removed from source). Both of
> them have changes that can be seen by users, so can't see why we would
> want them removed.
>
> - Merge Join performance has been substantially improved by ring buffer
> which avoids materializing the previous sort step. (Simon, Greg)
>
> More info, not for release notes:
> The materialization of the prior sort step would generally double the
> time taken for the sort, so avoiding this effectively gives a 50%
> performance gain on sorts that are part of large merge joins.
>
>
> - WAL file switches don't update controlfile any longer. Recovery now
> refers to the last checkpoint time, which may be many minutes earlier
> than time previously mentioned. (Simon, Tom)
>
> More info, not for release notes:
> WAL file switches were performed holding important LWLocks, so this
> improves scalability on high end systems as well as reducing response
> time spikes under heavy load on all kinds of hardware.

Let me give you the criteria I use for the release notes. The release
notes try to document all changes visible to the average user in a way
that is understandable to the average user.

The above items are probably neither visible (except faster) nor
understandable. Now of course we change change that criteria but that
is going to need a larger discussion.

One idea that would allow these to be included is a "geek" section of
the release notes that has items that would not be understandable by the
average user, e.g. optimizer improvements, locking improvements. It
would be kind of like "Postgres is faster in this release in some
obscure ways, and this is why". Of course the section would have to be
labeled clearly and it does open us up to the release notes being less
user-friendly.

Such a section seems to be more of a supplying a curiosity rather than
useful information, though.

I will address the issue of giving people credit for work in my next
email.

The good news is that we can keep adjusting the release notes until 8.3
final.

--
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. +