INDEX</literal> is invoked on a partitioned
   table, the default behavior is to recurse to all partitions to ensure
   they all have matching indexes.
   Each partition is first checked to determine whether an equivalent
   index already exists, and if so, that index will become attached as a
   partition index to the index being created, which will become its
   parent index.
   If no matching index exists, a new index will be created and
   automatically attached; the name of the new index in each partition
   will be determined as if no index name had been specified in the
   command.
   If the <literal>ONLY</literal> option is specified, no recursion
   is done, and the index is marked invalid.
   (<command>ALTER INDEX ... ATTACH PARTITION</command> marks the index
   valid, once all partitions acquire matching indexes.)  Note, however,
   that any partition that is created in the future using
   <command>CREATE TABLE ... PARTITION OF</command> will automatically
   have a matching index, regardless of whether <literal>ONLY</literal> is
   specified.
  </para>

  <para>
   For index methods that support ordered scans (currently, only B-tree),
   the optional clauses <literal>ASC</literal>, <literal>DESC</literal>, <literal>NULLS
   FIRST</literal>, and/or <literal>NULLS LAST</literal> can be specified to modify
   the sort ordering of the index.  Since an ordered index can be
   scanned either forward or backward, it is not normally useful to create a
   single-column <literal>DESC</literal> index &mdash; that sort ordering is already
   available with a regular index.  The value of these options is that
   multicolumn indexes can be created that match the sort ordering requested
   by a mixed-ordering query, such as <literal>SELECT ... ORDER BY x ASC, y
   DESC</literal>.  The <literal>NULLS</literal> options are useful if you need to support
   <quote>nulls sort low</quote> behavior, rather than the default <quote>nulls
   sort high</quote>, in queries that depend on indexes to avoid sorting steps.
  </para>

  <para>
   The system regularly collects statistics on all of a table's
   columns.  Newly-created non-expression indexes can immediately
   use these statistics to determine an index's usefulness.
   For new expression indexes, it is necessary to run <link
   linkend="sql-analyze"><command>ANALYZE</command></link> or wait for
   the <link linkend="autovacuum">autovacuum daemon</link> to analyze
   the table to generate statistics for these indexes.
  </para>

  <para>
   While <command>CREATE INDEX</command> is running, the <xref
   linkend="guc-search-path"/> is temporarily changed to <literal>pg_catalog,
   pg_temp</literal>.
  </para>

  <para>
   For most index methods, the speed of creating an index is
   dependent on the setting of <xref linkend="guc-maintenance-work-mem"/>.
   Larger values will reduce the time needed for index creation, so long
   as you don't make it larger than the amount of memory really available,
   which would drive the machine into swapping.
  </para>

  <para>
   <productname>PostgreSQL</productname> can build indexes while
   leveraging multiple CPUs in order to process the table rows faster.
   This feature is known as <firstterm>parallel index
   build</firstterm>.  For index methods that support building indexes
   in parallel (currently, B-tree and BRIN),
   <varname>maintenance_work_mem</varname> specifies the maximum
   amount of memory that can be used by each index build operation as
   a whole, regardless of how many worker processes were started.
   Generally, a cost model automatically determines how many worker
   processes should be requested, if any.
  </para>

  <para>
   Parallel index builds may benefit from increasing
   <varname>maintenance_work_mem</varname> where an equivalent serial
   index build will see little or no benefit.  Note that
   <varname>maintenance_work_mem</varname> may influence the number of
   worker processes requested, since parallel workers