Improvements to the backup & restore documentation.

diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index cff69b96a7427dcfe5d7c516bc99fc6285ee9522..b8b958296cc8c5434e947195990f8559838b12ce 100644 (file)
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1,5 +1,5 @@
 
 
  Backup and Restore
@@ -30,7 +30,7 @@ $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.38 2004/03/09 16:57:46 neilc Exp
    commands that, when fed back to the server, will recreate the
    database in the same state as it was at the time of the dump.
    PostgreSQL provides the utility program
-   <application>pg_dump> for this purpose. The basic usage of this
+   <xref linkend="app-pgdump"> for this purpose. The basic usage of this
    command is:
 
 pg_dump dbname > outfile
@@ -126,10 +126,11 @@ psql dbname < 
    
 
    
-    Once restored, it is wise to run ANALYZE on each
-    database so the optimizer has useful statistics. You
-    can also run vacuumdb -a -z to ANALYZE all
-    databases.
+    Once restored, it is wise to run 
+    endterm="sql-analyze-title"> on each database so the optimizer has
+    useful statistics. You can also run vacuumdb -a -z to
+    VACUUM ANALYZE all databases; this is equivalent to
+    running VACUUM ANALYZE manually.
    
 
    
@@ -153,13 +154,11 @@ pg_dump -h host1 dbname | psql -h h
     
    
 
-   
-    
-    Restore performance can be improved by increasing the
-    configuration parameter 
-    linkend="guc-maintenance-work-mem">.
-    
-   
+   
+    For advice on how to load large amounts of data into
+    PostgreSQL efficiently, refer to 
+    linkend="populate">.
+   
   
 
   
@@ -167,12 +166,11 @@ pg_dump -h host1 dbname | psql -h h
 
    
     The above mechanism is cumbersome and inappropriate when backing
-    up an entire database cluster. For this reason the
-    pg_dumpall> program is provided.
+    up an entire database cluster. For this reason the 
+    linkend="app-pg-dumpall"> program is provided.
     pg_dumpall backs up each database in a given
-    cluster, and also preserves cluster-wide data such as
-    users and groups. The call sequence for
-    pg_dumpall is simply
+    cluster, and also preserves cluster-wide data such as users and
+    groups. The basic usage of this command is:
 
 pg_dumpall > outfile
 
@@ -195,7 +193,7 @@ psql template1 < infile
     Since PostgreSQL allows tables larger
     than the maximum file size on your system, it can be problematic
     to dump such a table to a file, since the resulting file will likely
-    be larger than the maximum size allowed by your system. As
+    be larger than the maximum size allowed by your system. Since
     pg_dump can write to the standard output, you can
     just use standard Unix tools to work around this possible problem.
    
@@ -274,7 +272,7 @@ pg_dump -Fc dbname > 
     For reasons of backward compatibility, pg_dump
     does not dump large objects by default.large
     objectbackup To dump
-    large objects you must use either the custom or the TAR output
+    large objects you must use either the custom or the tar output
     format, and use the -b option in
     pg_dump. See the reference pages for details.  The
     directory contrib/pg_dumplo of the
@@ -315,11 +313,12 @@ tar -cf backup.tar /usr/local/pgsql/data
      
       The database server must be shut down in order to
       get a usable backup. Half-way measures such as disallowing all
-      connections will not work as there is always some buffering
-      going on. Information about stopping the server can be
-      found in .  Needless to say
-      that you also need to shut down the server before restoring the
-      data.
+      connections will not work
+      (tar and similar tools do not take an atomic
+      snapshot of the state of the filesystem at a point in
+      time). Information about stopping the server can be found in
+      .  Needless to say that you
+      also need to shut down the server before restoring the data.
      
     
 


diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml

index f8b1d47aa9e20588572733513c05e73f7a8cc2b1..e9a34ecad2b6175048012bb50182b5b9fd039fd9 100644 (file)

--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -28,8 +28,8 @@ $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.43 2004/03/25 18:57:57 tgl Exp
     plan for each query it is given.  Choosing the right
     plan to match the query structure and the properties of the data
     is absolutely critical for good performance.  You can use the
-    <command>EXPLAIN command to see what query plan the system
-    creates for any query.
+    <xref linkend="sql-explain" endterm="sql-explain-title"> command
+    to see what query plan the system creates for any query.
     Plan-reading is an art that deserves an extensive tutorial, which
     this is not; but here is some basic information.
    
@@ -638,30 +638,51 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    
 
    
-    Turn off autocommit and just do one commit at
-    the end.  (In plain SQL, this means issuing BEGIN
-    at the start and COMMIT at the end.  Some client
-    libraries may do this behind your back, in which case you need to
-    make sure the library does it when you want it done.)
-    If you allow each insertion to be committed separately,
-    PostgreSQL is doing a lot of work for each
-    row that is added.
-    An additional benefit of doing all insertions in one transaction
-    is that if the insertion of one row were to fail then the
-    insertion of all rows inserted up to that point would be rolled
-    back, so you won't be stuck with partially loaded data.
+    Turn off autocommit and just do one commit at the end.  (In plain
+    SQL, this means issuing BEGIN at the start and
+    COMMIT at the end.  Some client libraries may
+    do this behind your back, in which case you need to make sure the
+    library does it when you want it done.)  If you allow each
+    insertion to be committed separately,
+    PostgreSQL is doing a lot of work for
+    each row that is added.  An additional benefit of doing all
+    insertions in one transaction is that if the insertion of one row
+    were to fail then the insertion of all rows inserted up to that
+    point would be rolled back, so you won't be stuck with partially
+    loaded data.
+   
+
+   
+    If you are issuing a large sequence of INSERT
+    commands to bulk load some data, also consider using 
+    linkend="sql-prepare" endterm="sql-prepare-title"> to create a
+    prepared INSERT statement. Since you are
+    executing the same command multiple times, it is more efficient to
+    prepare the command once and then use EXECUTE
+    as many times as required.
    
   
 
   
-   Use <command>COPY FROM</command>
+   Use <command>COPY</command>
+
+   
+    Use  to load
+    all the rows in one command, instead of using a series of
+    INSERT commands.  The COPY
+    command is optimized for loading large numbers of rows; it is less
+    flexible than INSERT, but incurs significantly
+    less overhead for large data loads. Since COPY
+    is a single command, there is no need to disable autocommit if you
+    use this method to populate a table.
+   
 
    
-    Use COPY FROM STDIN to load all the rows in one
-    command, instead of using a series of INSERT
-    commands.  This reduces parsing, planning, etc.  overhead a great
-    deal. If you do this then it is not necessary to turn off
-    autocommit, since it is only one command anyway.
+    Note that loading a large number of rows using
+    COPY is almost always faster than using
+    INSERT, even if multiple
+    INSERT commands are batched into a single
+    transaction.
    
   
 
@@ -678,11 +699,12 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
 
    
     If you are augmenting an existing table, you can drop the index,
-    load the table, then recreate the index. Of
-    course, the database performance for other users may be adversely 
-    affected during the time that the index is missing.  One should also
-    think twice before dropping unique indexes, since the error checking
-    afforded by the unique constraint will be lost while the index is missing.
+    load the table, and then recreate the index. Of course, the
+    database performance for other users may be adversely affected
+    during the time that the index is missing.  One should also think
+    twice before dropping unique indexes, since the error checking
+    afforded by the unique constraint will be lost while the index is
+    missing.
    
   
 
@@ -701,16 +723,39 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    
   
 
+  
+   Increase <varname>checkpoint_segments</varname>
+
+   
+    Temporarily increasing the 
+    linkend="guc-checkpoint-segments"> configuration variable can also
+    make large data loads faster.  This is because loading a large
+    amount of data into PostgreSQL can
+    cause checkpoints to occur more often than the normal checkpoint
+    frequency (specified by the checkpoint_timeout
+    configuration variable). Whenever a checkpoint occurs, all dirty
+    pages must be flushed to disk. By increasing
+    checkpoint_segments temporarily during bulk
+    data loads, the number of checkpoints that are required can be
+    reduced.
+   
+  
+
   
    Run <command>ANALYZE</command> Afterwards
 
    
-    It's a good idea to run ANALYZE or VACUUM
-    ANALYZE anytime you've added or updated a lot of data,
-    including just after initially populating a table.  This ensures that
-    the planner has up-to-date statistics about the table.  With no statistics
-    or obsolete statistics, the planner may make poor choices of query plans,
-    leading to bad performance on queries that use your table.
+    Whenever you have significantly altered the distribution of data
+    within a table, running 
+    endterm="sql-analyze-title"> is strongly recommended. This
+    includes when bulk loading large amounts of data into
+    PostgreSQL.  Running
+    ANALYZE (or VACUUM ANALYZE)
+    ensures that the planner has up-to-date statistics about the
+    table.  With no statistics or obsolete statistics, the planner may
+    make poor decisions during query planning, leading to poor
+    performance on any tables with inaccurate or nonexistent
+    statistics.
    
   
   




This is the main PostgreSQL git repository.
RSS
Atom



window.onload = function () {
	var tz_cookie = { name: 'gitweb_tz', expires: 14, path: '/' };
	onloadTZSetup('local', tz_cookie, 'datetime');
};

diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
index f8b1d47aa9e20588572733513c05e73f7a8cc2b1..e9a34ecad2b6175048012bb50182b5b9fd039fd9 100644 (file)
--- a/doc/src/sgml/perform.sgml
+++ b/doc/src/sgml/perform.sgml
@@ -1,5 +1,5 @@
 
 
  
@@ -28,8 +28,8 @@ $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.43 2004/03/25 18:57:57 tgl Exp
     plan for each query it is given.  Choosing the right
     plan to match the query structure and the properties of the data
     is absolutely critical for good performance.  You can use the
-    <command>EXPLAIN command to see what query plan the system
-    creates for any query.
+    <xref linkend="sql-explain" endterm="sql-explain-title"> command
+    to see what query plan the system creates for any query.
     Plan-reading is an art that deserves an extensive tutorial, which
     this is not; but here is some basic information.
    
@@ -638,30 +638,51 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    
 
    
-    Turn off autocommit and just do one commit at
-    the end.  (In plain SQL, this means issuing BEGIN
-    at the start and COMMIT at the end.  Some client
-    libraries may do this behind your back, in which case you need to
-    make sure the library does it when you want it done.)
-    If you allow each insertion to be committed separately,
-    PostgreSQL is doing a lot of work for each
-    row that is added.
-    An additional benefit of doing all insertions in one transaction
-    is that if the insertion of one row were to fail then the
-    insertion of all rows inserted up to that point would be rolled
-    back, so you won't be stuck with partially loaded data.
+    Turn off autocommit and just do one commit at the end.  (In plain
+    SQL, this means issuing BEGIN at the start and
+    COMMIT at the end.  Some client libraries may
+    do this behind your back, in which case you need to make sure the
+    library does it when you want it done.)  If you allow each
+    insertion to be committed separately,
+    PostgreSQL is doing a lot of work for
+    each row that is added.  An additional benefit of doing all
+    insertions in one transaction is that if the insertion of one row
+    were to fail then the insertion of all rows inserted up to that
+    point would be rolled back, so you won't be stuck with partially
+    loaded data.
+   
+
+   
+    If you are issuing a large sequence of INSERT
+    commands to bulk load some data, also consider using 
+    linkend="sql-prepare" endterm="sql-prepare-title"> to create a
+    prepared INSERT statement. Since you are
+    executing the same command multiple times, it is more efficient to
+    prepare the command once and then use EXECUTE
+    as many times as required.
    
   
 
   
-   Use <command>COPY FROM</command>
+   Use <command>COPY</command>
+
+   
+    Use  to load
+    all the rows in one command, instead of using a series of
+    INSERT commands.  The COPY
+    command is optimized for loading large numbers of rows; it is less
+    flexible than INSERT, but incurs significantly
+    less overhead for large data loads. Since COPY
+    is a single command, there is no need to disable autocommit if you
+    use this method to populate a table.
+   
 
    
-    Use COPY FROM STDIN to load all the rows in one
-    command, instead of using a series of INSERT
-    commands.  This reduces parsing, planning, etc.  overhead a great
-    deal. If you do this then it is not necessary to turn off
-    autocommit, since it is only one command anyway.
+    Note that loading a large number of rows using
+    COPY is almost always faster than using
+    INSERT, even if multiple
+    INSERT commands are batched into a single
+    transaction.
    
   
 
@@ -678,11 +699,12 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
 
    
     If you are augmenting an existing table, you can drop the index,
-    load the table, then recreate the index. Of
-    course, the database performance for other users may be adversely 
-    affected during the time that the index is missing.  One should also
-    think twice before dropping unique indexes, since the error checking
-    afforded by the unique constraint will be lost while the index is missing.
+    load the table, and then recreate the index. Of course, the
+    database performance for other users may be adversely affected
+    during the time that the index is missing.  One should also think
+    twice before dropping unique indexes, since the error checking
+    afforded by the unique constraint will be lost while the index is
+    missing.
    
   
 
@@ -701,16 +723,39 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    
   
 
+  
+   Increase <varname>checkpoint_segments</varname>
+
+   
+    Temporarily increasing the 
+    linkend="guc-checkpoint-segments"> configuration variable can also
+    make large data loads faster.  This is because loading a large
+    amount of data into PostgreSQL can
+    cause checkpoints to occur more often than the normal checkpoint
+    frequency (specified by the checkpoint_timeout
+    configuration variable). Whenever a checkpoint occurs, all dirty
+    pages must be flushed to disk. By increasing
+    checkpoint_segments temporarily during bulk
+    data loads, the number of checkpoints that are required can be
+    reduced.
+   
+  
+
   
    Run <command>ANALYZE</command> Afterwards
 
    
-    It's a good idea to run ANALYZE or VACUUM
-    ANALYZE anytime you've added or updated a lot of data,
-    including just after initially populating a table.  This ensures that
-    the planner has up-to-date statistics about the table.  With no statistics
-    or obsolete statistics, the planner may make poor choices of query plans,
-    leading to bad performance on queries that use your table.
+    Whenever you have significantly altered the distribution of data
+    within a table, running 
+    endterm="sql-analyze-title"> is strongly recommended. This
+    includes when bulk loading large amounts of data into
+    PostgreSQL.  Running
+    ANALYZE (or VACUUM ANALYZE)
+    ensures that the planner has up-to-date statistics about the
+    table.  With no statistics or obsolete statistics, the planner may
+    make poor decisions during query planning, leading to poor
+    performance on any tables with inaccurate or nonexistent
+    statistics.
    
   
   




This is the main PostgreSQL git repository.
RSS
Atom