Skip to content

Commit fa25beb

Browse files
committed
docs: Changing column type doesn't always require an index rebuild.
James Coleman and Robert Haas, reviewed by Matthias van de Meent. Discussion: https://postgr.es/m/CAAaqYe90Ea3RG=A7H-ONvTcx549-oQhp07BrHErwM=AyH2ximg@mail.gmail.com
1 parent af9e180 commit fa25beb

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

doc/src/sgml/ref/alter_table.sgml

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1366,7 +1366,13 @@ WITH ( MODULUS <replaceable class="parameter">numeric_literal</replaceable>, REM
13661366
existing column, if the <literal>USING</literal> clause does not change
13671367
the column contents and the old type is either binary coercible to the new
13681368
type or an unconstrained domain over the new type, a table rewrite is not
1369-
needed; but any indexes on the affected columns must still be rebuilt.
1369+
needed. However, indexes must always be rebuilt unless the system can
1370+
verify that the new index would be logically equivalent to the existing
1371+
one. For example, if the collation for a column has been changed an index
1372+
rebuild is always required because the new sort order might be different.
1373+
However, in the absence of a collation change, a column can be changed
1374+
from <type>text</type> to <type>varchar</type> (or vice versa) without
1375+
rebuilding the indexes because these data types sort identically.
13701376
Table and/or index rebuilds may take a
13711377
significant amount of time for a large table; and will temporarily require
13721378
as much as double the disk space.

0 commit comments

Comments
 (0)