@@ -750,8 +750,9 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
750
750
751
751
<para>
752
752
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
+
755
756
</para>
756
757
757
758
<para>
@@ -777,6 +778,23 @@ analyze threshold = analyze base threshold + analyze scale factor * number of tu
777
778
(This consideration does not apply to non-B-tree indexes.) It
778
779
might be worthwhile to reindex periodically just to improve access speed.
779
780
</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>
780
798
</sect1>
781
799
782
800
0 commit comments