Re: Draft release notes complete

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Peter Geoghegan <peter(at)2ndquadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Draft release notes complete
Date: 2012-05-10 17:44:23
Message-ID: 20120510174423.GY16881@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote:
> On 10 May 2012 04:11, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > I have completed my draft of the 9.2 release notes, and committed it to
> > git.  I am waiting for our development docs to build, but after 40
> > minutes, I am still waiting:
>
> "Allow the bgwriter, walwriter, and statistics collector to sleep more
> efficiently during periods of inactivity (Peter Geoghegan, Heikki
> Linnakangas, Tom Lane)...This reduces CPU wake-ups."
>
> I think that there should be mention of why this is a good thing. When
> fully idle the server reaches less than a single wake-up per second,

I added text that says it reduces power consuption on idle servers.

> which I think is a nice, relevant fact. You should add the archiver
> and checkpointer to that list, though I suppose you could argue that
> the checkpointer, as a "new" auxiliary process, shouldn't count.

I added the archiver and checkpointer to the list. Seems there is no
doc section to link to for these processes.

> Why can't we call group commit group commit (and for that matter,
> index-only scans index-only scans), so that people will understand
> that we are now competitive with other RDBMSs in this area? "Improve
> performance of WAL writes when multiple transactions commit at the
> same time" seems like a pretty bad description, since it doesn't make
> any reference to batching of commits. Also, I don't think that the

I didn't call it "group commit" because we have settings we used to
regard as group commit:

#commit_delay = 0 # range 0-100000, in microseconds
#commit_siblings = 5 # range 1-1000

These are still there. Should they be removed?

I updated the release docs to call the item "group commit" because I now
don't see any reference to that term in our docs.

> placement of this as the second to last performance feature is
> commensurate with its actual importance. Still, the actual major

I am really unclear on how the performance items should be listed in
terms of importance, so I am ready for someone to tell me the proper
order.

> feature list is a much more relevant indicator of how it is felt that
> individual features should be weighed, and of course that hasn't been
> decided upon yet.
>
> "Change pg_stat_statements' total_time column to be measured in
> milliseconds (Tom Lane)". Surely this should be under
> "pg_stat_statements"?

I had it above because it was a major incompatibility. I do have some
incompatibilities, e.g. pg_upgrade, that I kept in their own section.
Should I move it? Can we assume people will also look in per-module
sections for incompatibility information?

> Does "Make the visibility map crash-safe" really belong under "Performance"?

Not sure where to move that to. Source Code doesn't seem right. I
moved it lower in the performance section.

> It's not clear that this isn't just within comments that will be later
> removed, but I'd remove all references to "we".

Fixed. Attached patch applied. Thanks.

I do appreciate all the feedback. I think I got almost zero feedback on
9.1 and it was kind of weird.

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

+ It's impossible for everything to be true. +

Attachment Content-Type Size
release.diff text/x-diff 4.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-05-10 17:45:00 Re: PL/Python result set slicing broken in Python 3
Previous Message Peter Eisentraut 2012-05-10 17:29:30 Re: Draft release notes complete