</indexterm>
    </term>
    <listitem>
     <para>
      This form sets the storage mode for a column. This controls whether this
      column is held inline or in a secondary <acronym>TOAST</acronym> table,
      and whether the data
      should be compressed or not. <literal>PLAIN</literal> must be used
      for fixed-length values such as <type>integer</type> and is
      inline, uncompressed. <literal>MAIN</literal> is for inline,
      compressible data. <literal>EXTERNAL</literal> is for external,
      uncompressed data, and <literal>EXTENDED</literal> is for external,
      compressed data.
      Writing <literal>DEFAULT</literal> sets the storage mode to the default
      mode for the column's data type.  <literal>EXTENDED</literal> is the
      default for most data types that support non-<literal>PLAIN</literal>
      storage.
      Use of <literal>EXTERNAL</literal> will make substring operations on
      very large <type>text</type> and <type>bytea</type> values run faster,
      at the penalty of increased storage space.
      Note that <literal>ALTER TABLE ... SET STORAGE</literal> doesn't itself
      change anything in the table; it just sets the strategy to be pursued
      during future table updates.
      See <xref linkend="storage-toast"/> for more information.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-altertable-desc-set-compression">
    <term>
     <literal>SET COMPRESSION <replaceable class="parameter">compression_method</replaceable></literal>
    </term>
    <listitem>
     <para>
      This form sets the compression method for a column, determining how
      values inserted in future will be compressed (if the storage mode
      permits compression at all).
      This does not cause the table to be rewritten, so existing data may still
      be compressed with other compression methods.  If the table is restored
      with <application>pg_restore</application>, then all values are rewritten
      with the configured compression method.
      However, when data is inserted from another relation (for example,
      by <command>INSERT ... SELECT</command>), values from the source table are
      not necessarily detoasted, so any previously compressed data may retain
      its existing compression method, rather than being recompressed with the
      compression method of the target column.
      The supported compression
      methods are <literal>pglz</literal> and <literal>lz4</literal>.
      (<literal>lz4</literal> is available only if <option>--with-lz4</option>
      was used when building <productname>PostgreSQL</productname>.)  In
      addition, <replaceable class="parameter">compression_method</replaceable>
      can be <literal>default</literal>, which selects the default behavior of
      consulting the <xref linkend="guc-default-toast-compression"/> setting
      at the time of data insertion to determine the method to use.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-altertable-desc-add-table-constraint">
    <term><literal>ADD <replaceable class="parameter">table_constraint</replaceable> [ NOT VALID ]</literal></term>
    <listitem>
     <para>
      This form adds a new constraint to a table using the same constraint
      syntax as <link linkend="sql-createtable"><command>CREATE TABLE</command></link>, plus the option <literal>NOT
      VALID</literal>, which is currently only allowed for foreign key,
      <literal>CHECK</literal> constraints and not-null constraints.
     </para>

     <para>
      Normally, this form will cause a scan of the table to verify that all
      existing rows in the table satisfy the new constraint.  But if
      the <literal>NOT VALID</literal> option is used, this
      potentially-lengthy scan is skipped.  The constraint will still be
      enforced against subsequent inserts or updates (that is, they'll fail
      unless there is a matching row in the referenced table, in the case
      of