On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan wrote:
> On 10 May 2012 04:11, Bruce Momjian <[email protected]> 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 <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
commit ffda90f3afe3f4db10127d2b853dfe4230720873
Author: Bruce Momjian <[email protected]>
Date: Thu May 10 13:38:05 2012 -0400
9.2 release note updates from Peter Geoghegan
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
new file mode 100644
index 0b43c3a..ed8ce99
*** a/doc/src/sgml/release-9.2.sgml
--- b/doc/src/sgml/release-9.2.sgml
***************
*** 72,79 ****
<para>
Users should now use hstore(text, text). Since
! <productname>PostgreSQL</productname> 9.0, we have emitted a
! warning message when an operator named => is created because
the <acronym>SQL</acronym> standard reserves that token for
another use.
</para>
--- 72,79 ----
<para>
Users should now use hstore(text, text). Since
! <productname>PostgreSQL</productname> 9.0, a warning message is
! emitted when an operator named => is created because
the <acronym>SQL</acronym> standard reserves that token for
another use.
</para>
***************
*** 462,478 ****
<listitem>
<para>
- Make the visibility map crash-safe (Robert Haas, Noah Misch)
- </para>
-
- <para>
- This helps vacuum be more efficient, and is necessary for
- index-only scans.
- </para>
- </listitem>
-
- <listitem>
- <para>
Improve GiST box and point index performance by producing better
trees with less memory allocation overhead (Alexander Korotkov,
Heikki Linnakangas, Kevin Grittner)
--- 462,467 ----
***************
*** 545,553 ****
<listitem>
<para>
! Improve performance of <acronym>WAL</acronym> writes when multiple
! transactions commit at the same time (Peter Geoghegan, Simon Riggs,
! Heikki Linnakangas)
</para>
</listitem>
--- 534,552 ----
<listitem>
<para>
! Improve performance of <acronym>WAL</acronym> writes using group
! commit (Peter Geoghegan, Simon Riggs, Heikki Linnakangas)
! </para>
! </listitem>
!
! <listitem>
! <para>
! Make the visibility map crash-safe (Robert Haas, Noah Misch)
! </para>
!
! <para>
! This helps vacuum be more efficient, and is necessary for
! index-only scans.
</para>
</listitem>
***************
*** 608,621 ****
<listitem>
<para>
Allow the <link linkend="pg-stat-bgwriter-view">bgwriter</link>,
! <link linkend="guc-wal-writer-delay">walwriter</link>, and <link
! linkend="monitoring-stats">statistics collector</link> to sleep
! more efficiently during periods of inactivity (Peter Geoghegan,
! Heikki Linnakangas, Tom Lane)
</para>
<para>
! This reduces <acronym>CPU</acronym> wake-ups.
</para>
</listitem>
--- 607,621 ----
<listitem>
<para>
Allow the <link linkend="pg-stat-bgwriter-view">bgwriter</link>,
! <link linkend="guc-wal-writer-delay">walwriter</link>, <link
! linkend="monitoring-stats">statistics collector</link>, archiver,
! and checkpointer to sleep more efficiently during periods of
! inactivity (Peter Geoghegan, Heikki Linnakangas, Tom Lane)
</para>
<para>
! This reduces <acronym>CPU</acronym> wake-ups, which dramatically
! reduces power consumption on idle servers.
</para>
</listitem>
***************
*** 2071,2077 ****
</para>
<para>
! We already supported minor-version-specific <filename>.psqlrc</>
files.
</para>
</listitem>
--- 2071,2078 ----
</para>
<para>
! <application>psql</> already supported minor-version-specific
! <filename>.psqlrc</>
files.
</para>
</listitem>
***************
*** 2745,2751 ****
<para>
Specifically, only lock the old cluster if link mode is used,
! and do it right after we restore the schema.
</para>
</listitem>
--- 2746,2752 ----
<para>
Specifically, only lock the old cluster if link mode is used,
! and do it right after the schema is restored.
</para>
</listitem>
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
