Update journaling performance docs based on comments by Michael Renner.

diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml
index 3b013746a313306c2f0b3f8ba711fd47e7f3c35f..e69463a9e22ce5ccbcc2063f615879f9d2eac3fd 100644 (file)
--- a/doc/src/sgml/wal.sgml
+++ b/doc/src/sgml/wal.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.54 2008/12/06 21:34:27 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.55 2008/12/10 11:05:49 momjian Exp $ -->
 
 <chapter id="wal">
  <title>Reliability and the Write-Ahead Log</title>
@@ -139,13 +139,13 @@
     <para>
      Because <acronym>WAL</acronym> restores database file
      contents after a crash, it is not necessary to use a
-     journaled filesystem;  in fact, journaling overhead can
-     reduce performance.  For best performance, turn off
-     <emphasis>data</emphasis> journaling as a filesystem mount
-     option, e.g. use <literal>data=writeback</> on Linux.
-     Meta-data journaling (e.g.  file creation and directory
-     modification) is still desirable for faster rebooting after
-     a crash.
+     journaled filesystem for reliability.  In fact, journaling
+     overhead can reduce performance, especially if journaling
+     causes file system <emphasis>data</emphasis> to be flushed
+     to disk.  Fortunately, data flushing during journaling can
+     often be disabled with a filesystem mount option, e.g.
+     <literal>data=writeback</> on a Linux ext3 file system.
+     Journaled file systems do improve boot speed after a crash.
     </para>
    </tip>