<xref linkend="vacuum-for-statistics"/>
    and <xref linkend="autovacuum"/> for more information.
    For more advice on how to load large amounts of data
    into <productname>PostgreSQL</productname> efficiently, refer to <xref
    linkend="populate"/>.
   </para>
  </sect2>

  <sect2 id="backup-dump-all">
   <title>Using <application>pg_dumpall</application></title>

   <para>
    <application>pg_dump</application> dumps only a single database at a time,
    and it does not dump information about roles or tablespaces
    (because those are cluster-wide rather than per-database).
    To support convenient dumping of the entire contents of a database
    cluster, the <xref linkend="app-pg-dumpall"/> program is provided.
    <application>pg_dumpall</application> backs up each database in a given
    cluster, and also preserves cluster-wide data such as role and
    tablespace definitions. The basic usage of this command is:
<synopsis>
pg_dumpall &gt; <replaceable>dumpfile</replaceable>
</synopsis>
    The resulting dump can be restored with <application>psql</application>:
<synopsis>
psql -X -f <replaceable class="parameter">dumpfile</replaceable> postgres
</synopsis>
    (Actually, you can specify any existing database name to start from,
    but if you are loading into an empty cluster then <literal>postgres</literal>
    should usually be used.)  It is always necessary to have
    database superuser access when restoring a <application>pg_dumpall</application>
    dump, as that is required to restore the role and tablespace information.
    If you use tablespaces, make sure that the tablespace paths in the
    dump are appropriate for the new installation.
   </para>

   <para>
    <application>pg_dumpall</application> works by emitting commands to re-create
    roles, tablespaces, and empty databases, then invoking
    <application>pg_dump</application> for each database.  This means that while
    each database will be internally consistent, the snapshots of
    different databases are not synchronized.
   </para>

   <para>
    Cluster-wide data can be dumped alone using the
    <application>pg_dumpall</application> <option>--globals-only</option> option.
    This is necessary to fully backup the cluster if running the
    <application>pg_dump</application> command on individual databases.
   </para>
  </sect2>

  <sect2 id="backup-dump-large">
   <title>Handling Large Databases</title>

   <para>
    Some operating systems have maximum file size limits that cause
    problems when creating large <application>pg_dump</application> output files.
    Fortunately, <application>pg_dump</application> can write to the standard
    output, so you can use standard Unix tools to work around this
    potential problem.  There are several possible methods:
   </para>

   <formalpara>
    <title>Use compressed dumps.</title>
    <para>
     You can use your favorite compression program, for example
     <application>gzip</application>:

<programlisting>
pg_dump <replaceable class="parameter">dbname</replaceable> | gzip &gt; <replaceable class="parameter">filename</replaceable>.gz
</programlisting>

     Reload with:

<programlisting>
gunzip -c <replaceable class="parameter">filename</replaceable>.gz | psql <replaceable class="parameter">dbname</replaceable>
</programlisting>

     or:

<programlisting>
cat <replaceable class="parameter">filename</replaceable>.gz | gunzip | psql <replaceable class="parameter">dbname</replaceable>
</programlisting>
    </para>
   </formalpara>

   <formalpara>
    <title>Use <command>split</command>.</title>
    <para>
     The <command>split</command> command
     allows you to split the output into smaller files that are
     acceptable in size to the underlying file system. For example, to
     make 2 gigabyte chunks:

<programlisting>
pg_dump <replaceable class="parameter">dbname</replaceable> | split -b 2G - <replaceable class="parameter">filename</replaceable>
</programlisting>

     Reload with: