</para>

  <para>
   Reindexing partitioned indexes or partitioned tables is supported
   with <command>REINDEX INDEX</command> or <command>REINDEX TABLE</command>,
   respectively. Each partition of the specified partitioned relation is
   reindexed in a separate transaction. Those commands cannot be used inside
   a transaction block when working on a partitioned table or index.
  </para>

  <para>
   When using the <literal>TABLESPACE</literal> clause with
   <command>REINDEX</command> on a partitioned index or table, only the
   tablespace references of the leaf partitions are updated. As partitioned
   indexes are not updated, it is recommended to separately use
   <command>ALTER TABLE ONLY</command> on them so as any new partitions
   attached inherit the new tablespace. On failure, it may not have moved
   all the indexes to the new tablespace. Re-running the command will rebuild
   all the leaf partitions and move previously-unprocessed indexes to the new
   tablespace.
  </para>

  <para>
   If <literal>SCHEMA</literal>, <literal>DATABASE</literal> or
   <literal>SYSTEM</literal> is used with <literal>TABLESPACE</literal>,
   system relations are skipped and a single <literal>WARNING</literal>
   will be generated. Indexes on TOAST tables are rebuilt, but not moved
   to the new tablespace.
  </para>

  <refsect2 id="sql-reindex-concurrently" xreflabel="Rebuilding Indexes Concurrently">
   <title>Rebuilding Indexes Concurrently</title>

   <indexterm zone="sql-reindex-concurrently">
    <primary>index</primary>
    <secondary>rebuilding concurrently</secondary>
   </indexterm>

   <para>
    Rebuilding an index can interfere with regular operation of a database.
    Normally <productname>PostgreSQL</productname> locks the table whose index is rebuilt
    against writes and performs the entire index build with a single scan of the
    table. Other transactions can still read the table, but if they try to
    insert, update, or delete rows in the table they will block until the
    index rebuild is finished. This could have a severe effect if the system is
    a live production database. Very large tables can take many hours to be
    indexed, and even for smaller tables, an index rebuild can lock out writers
    for periods that are unacceptably long for a production system.
   </para>

   <para>
    <productname>PostgreSQL</productname> supports rebuilding indexes with minimum locking
    of writes.  This method is invoked by specifying the
    <literal>CONCURRENTLY</literal> option of <command>REINDEX</command>. When this option
    is used, <productname>PostgreSQL</productname> must perform two scans of the table
    for each index that needs to be rebuilt and wait for termination of
    all existing transactions that could potentially use the index.
    This method requires more total work than a standard index
    rebuild and takes significantly longer to complete as it needs to wait
    for unfinished transactions that might modify the index. However, since
    it allows normal operations to continue while the index is being rebuilt, this
    method is useful for rebuilding indexes in a production environment. Of
    course, the extra CPU, memory and I/O load imposed by the index rebuild
    may slow down other operations.
   </para>

   <para>
    The following steps occur in a concurrent reindex.  Each step is run in a
    separate transaction.  If there are multiple indexes to be rebuilt, then
    each step loops through all the indexes before moving to the next step.

    <orderedlist>
     <listitem>
      <para>
       A new transient index definition is added to the catalog
       <literal>pg_index</literal>.  This definition will be used to replace
       the old index.  A <literal>SHARE UPDATE EXCLUSIVE</literal> lock at
       session level is taken on the indexes being reindexed as well as their
       associated tables to prevent any schema modification while processing.
      </para>
     </listitem>