faster,
      at the penalty of increased storage space.
      See <xref linkend="storage-toast"/> for more information.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry id="sql-createtable-parms-compression">
    <term><literal>COMPRESSION <replaceable class="parameter">compression_method</replaceable></literal></term>
    <listitem>
     <para>
      The <literal>COMPRESSION</literal> clause sets the compression method
      for the column.  Compression is supported only for variable-width data
      types, and is used only when the column's storage mode
      is <literal>main</literal> or <literal>extended</literal>.
      (See <xref linkend="sql-altertable"/> for information on
      column storage modes.) Setting this property for a partitioned table
      has no direct effect, because such tables have no storage of their own,
      but the configured value will be inherited by newly-created partitions.
      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> to explicitly specify the default
      behavior, which is to consult 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-createtable-parms-inherits">
    <term><literal>INHERITS ( <replaceable>parent_table</replaceable> [, ... ] )</literal></term>
    <listitem>
     <para>
      The optional <literal>INHERITS</literal> clause specifies a list of
      tables from which the new table automatically inherits all
      columns.  Parent tables can be plain tables or foreign tables.
     </para>

     <para>
      Use of <literal>INHERITS</literal> creates a persistent relationship
      between the new child table and its parent table(s).  Schema
      modifications to the parent(s) normally propagate to children
      as well, and by default the data of the child table is included in
      scans of the parent(s).
     </para>

     <para>
      If the same column name exists in more than one parent
      table, an error is reported unless the data types of the columns
      match in each of the parent tables.  If there is no conflict,
      then the duplicate columns are merged to form a single column in
      the new table.  If the column name list of the new table
      contains a column name that is also inherited, the data type must
      likewise match the inherited column(s), and the column
      definitions are merged into one.  If the
      new table explicitly specifies a default value for the column,
      this default overrides any defaults from inherited declarations
      of the column.  Otherwise, any parents that specify default
      values for the column must all specify the same default, or an
      error will be reported.
     </para>

     <para>
      <literal>CHECK</literal> constraints are merged in essentially the same way as
      columns: if multiple parent tables and/or the new table definition
      contain identically-named <literal>CHECK</literal> constraints, these
      constraints must all have the same check expression, or an error will be
      reported.  Constraints having the same name and expression will
      be merged into one copy.  A constraint marked <literal>NO INHERIT</literal> in a
      parent will not be considered.  Notice that an unnamed <literal>CHECK</literal>
      constraint in the new table will never be merged, since a unique name
      will always be chosen for it.
     </para>

     <para>
      Column <literal>STORAGE</literal> settings are also copied from parent tables.
     </para>

     <para>
      If a column in the parent