mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update journaling performance docs based on comments by Michael Renner.

Browse Source
This commit is contained in:
Bruce Momjian 2008-12-10 11:05:49 +00:00
parent 5932915fef
commit 253fa736b9
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
doc/src/sgml/wal.sgml
View File

@ -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"> <chapter id="wal">
<title>Reliability and the Write-Ahead Log</title> <title>Reliability and the Write-Ahead Log</title>
@ -139,13 +139,13 @@
<para> <para>
Because <acronym>WAL</acronym> restores database file Because <acronym>WAL</acronym> restores database file
contents after a crash, it is not necessary to use a contents after a crash, it is not necessary to use a
journaled filesystem; in fact, journaling overhead can journaled filesystem for reliability. In fact, journaling
reduce performance. For best performance, turn off overhead can reduce performance, especially if journaling
<emphasis>data</emphasis> journaling as a filesystem mount causes file system <emphasis>data</emphasis> to be flushed
option, e.g. use <literal>data=writeback</> on Linux. to disk. Fortunately, data flushing during journaling can
Meta-data journaling (e.g. file creation and directory often be disabled with a filesystem mount option, e.g.
modification) is still desirable for faster rebooting after <literal>data=writeback</> on a Linux ext3 file system.
a crash. Journaled file systems do improve boot speed after a crash.
</para> </para>
</tip> </tip>