@@ -748,8 +748,9 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
748748
749749 <para>
750750 In some situations it is worthwhile to rebuild indexes periodically
751- with the <xref linkend="sql-reindex">
752- command.
751+ with the <xref linkend="sql-reindex"> command or a series of individual
752+ rebuilding steps.
753+
753754 </para>
754755
755756 <para>
@@ -775,6 +776,23 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
775776 (This consideration does not apply to non-B-tree indexes.) It
776777 might be worthwhile to reindex periodically just to improve access speed.
777778 </para>
779+
780+ <para>
781+ <xref linkend="sql-reindex"> can be used safely and easily in all cases.
782+ But since the command requires an exclusive table lock, it is
783+ often preferable to execute an index rebuild with a sequence of
784+ creation and replacement steps. Index types that support
785+ <xref linkend="sql-createindex"> with the <literal>CONCURRENTLY</>
786+ option can instead be recreated that way. If that is successful and the
787+ resulting index is valid, the original index can then be replaced by
788+ the newly built one using a combination of <xref linkend="sql-alterindex">
789+ and <xref linkend="sql-dropindex">. When an index is used to enforce
790+ uniqueness or other constraints, <xref linkend="sql-altertable"> might
791+ be necessary to swap the existing constraint with one enforced by
792+ the new index. Review this alternate multi-step rebuild approach
793+ carefully before using it as there are limitations on which
794+ indexes can be reindexed this way, and errors must be handled.
795+ </para>
778796 </sect1>
779797
780798