<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 Settings</title>

   <indexterm zone="non-durability">
    <primary>non-durable</primary>
   </indexterm>

   <para>
    Durability is a database feature that guarantees the recording of
    committed transactions even if the server crashes or loses
    power.  However, durability adds significant database overhead,
    so if your site does not require such a guarantee,
    <productname>PostgreSQL</productname> can be configured to run
    much faster.  The following are configuration changes you can make
    to improve performance in such cases.  Except as noted below, durability
    is still guaranteed in case of a crash of the database software;
    only an abrupt operating system crash creates a risk of data loss
    or corruption when these settings are used.

    <itemizedlist>
     <listitem>
      <para>
       Place the database cluster's data directory in a memory-backed
       file system (i.e., <acronym>RAM</acronym> disk).  This eliminates all
       database disk I/O, but limits data storage to the amount of
       available memory (and perhaps swap).
      </para>
     </listitem>

     <listitem>
      <para>
       Turn off <xref linkend="guc-fsync"/>;  there is no need to flush
       data to disk.
      </para>
     </listitem>

     <listitem>
      <para>
       Turn off <xref linkend="guc-synchronous-commit"/>;  there might be no
       need to force <acronym>WAL</acronym> writes to disk on every
       commit.  This setting does risk transaction loss (though not data
       corruption) in case of a crash of the <emphasis>database</emphasis>.
      </para>
     </listitem>

     <listitem>
      <para>
       Turn off <xref linkend="guc-full-page-writes"/>;  there is no need
       to guard against partial page writes.
      </para>
     </listitem>

     <listitem>
      <para>
       Increase <xref linkend="guc-max-wal-size"/> and <xref
       linkend="guc-checkpoint-timeout"/>; this reduces the frequency
       of checkpoints, but increases the storage requirements of
       <filename>/pg_wal</filename>.
      </para>
     </listitem>

     <listitem>
      <para>
       Create <link linkend="sql-createtable-unlogged">unlogged
       tables</link> to avoid <acronym>WAL</acronym> writes, though it
       makes the tables non-crash-safe.
      </para>
     </listitem>

    </itemizedlist>
   </para>
  </sect1>

 </chapter>