|
1 |
| -<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.75 2010/04/03 07:22:55 petere Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.76 2010/04/20 00:26:06 rhaas Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter id="performance-tips">
|
4 | 4 | <title>Performance Tips</title>
|
@@ -910,24 +910,28 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
|
910 | 910 | </sect2>
|
911 | 911 |
|
912 | 912 | <sect2 id="populate-pitr">
|
913 |
| - <title>Turn off <varname>archive_mode</varname></title> |
| 913 | + <title>Turn off <varname>archive_mode</varname> and streaming replication</title> |
914 | 914 |
|
915 | 915 | <para>
|
916 | 916 | When loading large amounts of data into an installation that uses
|
917 |
| - WAL archiving, you might want to disable archiving (turn off the |
918 |
| - <xref linkend="guc-archive-mode"> configuration variable) |
| 917 | + WAL archiving or streaming replication, you might want to disable |
| 918 | + archiving (turn off the <xref linkend="guc-archive-mode"> |
| 919 | + configuration variable) and replication (zero the |
| 920 | + <xref linkend="guc-max-wal-senders"> configuration variable) |
919 | 921 | while loading. It might be
|
920 | 922 | faster to take a new base backup after the load has completed
|
921 | 923 | than to process a large amount of incremental WAL data.
|
922 |
| - But note that turning <varname>archive_mode</varname> on or off |
923 |
| - requires a server restart. |
| 924 | + But note that changing either of these variables requires |
| 925 | + a server restart. |
924 | 926 | </para>
|
925 | 927 |
|
926 | 928 | <para>
|
927 |
| - Aside from avoiding the time for the archiver to process the WAL data, |
| 929 | + Aside from avoiding the time for the archiver or WAL sender to |
| 930 | + process the WAL data, |
928 | 931 | doing this will actually make certain commands faster, because they
|
929 | 932 | are designed not to write WAL at all if <varname>archive_mode</varname>
|
930 |
| - is off. (They can guarantee crash safety more cheaply by doing an |
| 933 | + is off and <varname>max_wal_senders</varname> is zero. (They can |
| 934 | + guarantee crash safety more cheaply by doing an |
931 | 935 | <function>fsync</> at the end than by writing WAL.)
|
932 | 936 | This applies to the following commands:
|
933 | 937 | <itemizedlist>
|
|
0 commit comments