NOT EXISTS</literal></term>
      <listitem>
       <para>
        Do not throw an error if a relation with the same name already exists.
        A notice is issued in this case. Note that there is no guarantee that
        the existing index is anything like the one that would have been created.
        Index name is required when <literal>IF NOT EXISTS</literal> is specified.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>INCLUDE</literal></term>
      <listitem>
       <para>
        The optional <literal>INCLUDE</literal> clause specifies a
        list of columns which will be included in the index
        as <firstterm>non-key</firstterm> columns.  A non-key column cannot
        be used in an index scan search qualification, and it is disregarded
        for purposes of any uniqueness or exclusion constraint enforced by
        the index.  However, an index-only scan can return the contents of
        non-key columns without having to visit the index's table, since
        they are available directly from the index entry.  Thus, addition of
        non-key columns allows index-only scans to be used for queries that
        otherwise could not use them.
       </para>

       <para>
        It's wise to be conservative about adding non-key columns to an
        index, especially wide columns.  If an index tuple exceeds the
        maximum size allowed for the index type, data insertion will fail.
        In any case, non-key columns duplicate data from the index's table
        and bloat the size of the index, thus potentially slowing searches.
        Furthermore, B-tree deduplication is never used with indexes
        that have a non-key column.
       </para>

       <para>
        Columns listed in the <literal>INCLUDE</literal> clause don't need
        appropriate operator classes; the clause can include
        columns whose data types don't have operator classes defined for
        a given access method.
       </para>

       <para>
        Expressions are not supported as included columns since they cannot be
        used in index-only scans.
       </para>

       <para>
        Currently, the B-tree, GiST and SP-GiST index access methods support
        this feature.  In these indexes, the values of columns listed
        in the <literal>INCLUDE</literal> clause are included in leaf tuples
        which correspond to heap tuples, but are not included in upper-level
        index entries used for tree navigation.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">name</replaceable></term>
      <listitem>
       <para>
        The name of the index to be created.  No schema name can be included
        here; the index is always created in the same schema as its parent
        table.  The name of the index must be distinct from the name of any
        other relation (table, sequence, index, view, materialized view, or
        foreign table) in that schema.
        If the name is omitted, <productname>PostgreSQL</productname> chooses a
        suitable name based on the parent table's name and the indexed column
        name(s).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><literal>ONLY</literal></term>
      <listitem>
       <para>
        Indicates not to recurse creating indexes on partitions, if the
        table is partitioned.  The default is to recurse.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">table_name</replaceable></term>
      <listitem>
       <para>
        The name (possibly schema-qualified) of the table to be indexed.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><replaceable class="parameter">method</replaceable></term>
      <listitem>
       <para>
        The name of the index method to be used.  Choices are
        <literal>btree</literal>,