From bd9b9a289e276c745e5d8cd2208975362472c9ad Mon Sep 17 00:00:00 2001 From: jcoleman Date: Tue, 29 Mar 2022 13:56:39 +0000 Subject: [PATCH v3] Docs: Index rebuilding is sometimes skipped along with table rewriting In 367bc42 (for 9.2!) we "avoid index rebuild for no-rewrite ALTER TABLE .. ALTER TYPE." This doesn't apply in all cases, but update the docs to match so users don't conclude indexes must always be rewritten. --- doc/src/sgml/ref/alter_table.sgml | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml index 5c0735e08a..da576fcc89 100644 --- a/doc/src/sgml/ref/alter_table.sgml +++ b/doc/src/sgml/ref/alter_table.sgml @@ -1366,7 +1366,12 @@ WITH ( MODULUS numeric_literal, REM existing column, if the USING clause does not change the column contents and the old type is either binary coercible to the new type or an unconstrained domain over the new type, a table rewrite is not - needed; but any indexes on the affected columns must still be rebuilt. + needed. However, indexes must always be rebuilt unless the system can + verify that the new index would be logically equivalent to the existing one. + For example, while changing a column from type VARCHAR to type + TEXT (having the same collation) does not require rebuilding + indexes, a type change affecting the column's collation requires rebuilding + indexes because the logical sort order has changed. Table and/or index rebuilds may take a significant amount of time for a large table; and will temporarily require as much as double the disk space. -- 2.20.1