Home Explore Blog CI



postgresql

33th chunk of `doc/src/sgml/perform.sgml`
12100d92005aaa4d2eab7a11ac375a32946b23c28be5c3a30000000100000963
 significantly higher performance over the serial mode.
      </para>
     </listitem>
     <listitem>
      <para>
       Consider whether the whole dump should be restored as a single
       transaction.  To do that, pass the <option>-1</option> or
       <option>--single-transaction</option> command-line option to
       <application>psql</application> or <application>pg_restore</application>. When using this
       mode, even the smallest of errors will rollback the entire restore,
       possibly discarding many hours of processing.  Depending on how
       interrelated the data is, that might seem preferable to manual cleanup,
       or not.  <command>COPY</command> commands will run fastest if you use a single
       transaction and have WAL archiving turned off.
      </para>
     </listitem>
     <listitem>
      <para>
       If multiple CPUs are available in the database server, consider using
       <application>pg_restore</application>'s <option>--jobs</option> option.  This
       allows concurrent data loading and index creation.
      </para>
     </listitem>
     <listitem>
      <para>
       Run <command>ANALYZE</command> afterwards.
      </para>
     </listitem>
    </itemizedlist>
   </para>

   <para>
    A data-only dump will still use <command>COPY</command>, but it does not
    drop or recreate indexes, and it does not normally touch foreign
    keys.

     <footnote>
      <para>
       You can get the effect of disabling foreign keys by using
       the <option>--disable-triggers</option> option &mdash; but realize that
       that eliminates, rather than just postpones, foreign key
       validation, and so it is possible to insert bad data if you use it.
      </para>
     </footnote>

    So when loading a data-only dump, it is up to you to drop and recreate
    indexes and foreign keys if you wish to use those techniques.
    It's still useful to increase <varname>max_wal_size</varname>
    while loading the data, but don't bother increasing
    <varname>maintenance_work_mem</varname>; rather, you'd do that while
    manually recreating indexes and foreign keys afterwards.
    And don't forget to <command>ANALYZE</command> when you're done; see
    <xref linkend="vacuum-for-statistics"/>
    and <xref linkend="autovacuum"/> for more information.
   </para>
  </sect2>
  </sect1>

  <sect1 id="non-durability">
   <title>Non-Durable

Title: Optimizing PostgreSQL Data Restoration from pg_dump
Summary
To optimize data restoration from pg_dump, consider using parallel modes, single transactions, and multiple CPUs, and remember to run ANALYZE afterwards to ensure optimal performance, and also consider dropping and recreating indexes and foreign keys when loading data-only dumps.