Re: Draft release notes complete

On 12 May 2012 01:37, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Right.  It's not a new feature; it's a performance improvement.  We've
> had group commit for a long time; it just didn't work very well
> before.  And it's not batching the commits better; it's reducing the
> lock contention around realizing that the batched commit has happened.

This understanding of group commit is technically accurate, but the
practical implications of the new code are that lots of people benefit
from group commit, potentially to rather a large degree, where before
they had exactly no benefit from group commit. We never officially
called group commit group commit outside of git commit messages
before. Therefore, it is sort of like we didn't have group commit
before but now we do, and it's an implementation that's probably as
effective as that of any of our competitors. It is for that reason
that I suggested group commit get a more prominent billing, and that
it actually be officially referred to as group commit. I'm glad that
the release notes now actually refer to group commit.

Now, I realise that as one of the authors of the feature I am open to
accusations of lacking objectivity - clearly it isn't really my place
to try and influence the feature's placement, and this is the last I
will say on the matter unless someone else brings it up again. I just
think that pedantically characterising this as an improvement to our
existing group commit implementation within a document that will be
read like a press release is a bad decision, especially since our
competitors never had a group commit implementation that was far
inferior to their current implementation. The assumption will be that
it's a small improvement that's hardly worth noticing at all.

As to the question of whether or not we should include author names at
all, I personally wouldn't mind at all if we removed them, if that
would prevent squabbles, which it probably would. However, that's only
because I know that it wouldn't really affect my ability to work on
Postgres during my working day. I don't know that the same thing can
be said at all for people who don't work for one of the handful of
Postgres companies.

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services