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