Unexpected reindex when altering column types for partitioned tables

Started by Álvaro Rodríguez15 days ago4 messageshackers
Jump to latest
#1Álvaro Rodríguez
alvaro@datadoghq.com

Hi,

When running the ALTER TABLE ALTER COLUMN TYPE operation, certain type
changes are supposed to not require a reindex. For example, text to
varchar or varchar(n) to varchar(m) when m > n. However, this turns
out to not be the case for indexes (including pk / unique constraints)
on partitioned tables. Patch 0001 (attached) demonstrates this
behavior with a new regression test. In this case, the table rewrite
is avoided but the indexes are rebuilt.

During an alter column type for a partitioned table with an index, the
current deletion behavior:
1. Processes the parent table in ATRewriteCatalogs before
processing any of its child tables. This runs ATPostAlterTypeCleanup
for the table, which drops the partitioned index at the end. That drop
cascades to the child indexes.
2. Processes the child tables in ATRewriteCatalogs. However, the
child indexes were already dropped, so we never remember them in
RememberAllDependentForRebuilding.
3. When indexes are eventually recreated, they always need to be reindexed.

Patch 0002 batches the deletions in ATRewriteCatalogs so that they
happen at the end of a processing step and not in each call to
ATPostAlterTypeCleanup (which is called for each processed table).
This ensures that child indexes are tracked when ATExecAlterColumnType
calls RememberAllDependentForRebuilding for each child table.

After the change, child indexes are now recreated twice: once when the
parent index is created, and once by themselves. We need for the child
indexes to be created first. That way, they use the remembered
information to decide whether a reindex is needed. When the parent
index is created, it will automatically use existing child indexes. To
enforce this behavior, we add a new AT_PASS_OLD_PARTITIONED_INDEX that
recreates the parent indexes.

Finally, patch 0003 does very similar changes to index-backed
constraints. We make sure that the child constraints are properly
remembered. We also make sure that when the indexes for the child
constraints are rebuilt, the do so in the new
AT_PASS_OLD_PARTITIONED_INDEX step.

Thoughts?

Regards,
Álvaro Rodríguez

Attachments:

v1-0001-Add-regression-test-to-highlight-unexpected-behav.patchapplication/octet-stream; name=v1-0001-Add-regression-test-to-highlight-unexpected-behav.patchDownload+74-1
v1-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patchapplication/octet-stream; name=v1-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patchDownload+55-31
v1-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patchapplication/octet-stream; name=v1-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patchDownload+35-15
#2Alvaro Herrera
alvherre@2ndquadrant.com
In reply to: Álvaro Rodríguez (#1)
Re: Unexpected reindex when altering column types for partitioned tables

Hi,

On 2026-Jun-08, Álvaro Rodríguez wrote:

When running the ALTER TABLE ALTER COLUMN TYPE operation, certain type
changes are supposed to not require a reindex. For example, text to
varchar or varchar(n) to varchar(m) when m > n. However, this turns
out to not be the case for indexes (including pk / unique constraints)
on partitioned tables. Patch 0001 (attached) demonstrates this
behavior with a new regression test. In this case, the table rewrite
is avoided but the indexes are rebuilt.

I agree with the problem statement, and I think the proposed solution
has the right shape. This obviously has to be kept for pg20, so let's
discuss further during the next commitfest; please create a CF entry for
it.

Thanks,

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

#3Álvaro Rodríguez
alvaro@datadoghq.com
In reply to: Alvaro Herrera (#2)
Re: Unexpected reindex when altering column types for partitioned tables

Added to CF, thanks Álvaro!

Show quoted text

On Fri, Jun 12, 2026 at 3:03 PM Álvaro Herrera <alvherre@kurilemu.de> wrote:

Hi,

On 2026-Jun-08, Álvaro Rodríguez wrote:

When running the ALTER TABLE ALTER COLUMN TYPE operation, certain type
changes are supposed to not require a reindex. For example, text to
varchar or varchar(n) to varchar(m) when m > n. However, this turns
out to not be the case for indexes (including pk / unique constraints)
on partitioned tables. Patch 0001 (attached) demonstrates this
behavior with a new regression test. In this case, the table rewrite
is avoided but the indexes are rebuilt.

I agree with the problem statement, and I think the proposed solution
has the right shape. This obviously has to be kept for pg20, so let's
discuss further during the next commitfest; please create a CF entry for
it.

Thanks,

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/

#4Álvaro Rodríguez
alvaro@datadoghq.com
In reply to: Álvaro Rodríguez (#3)
Re: Unexpected reindex when altering column types for partitioned tables

I am also attaching a new version of the patches where we scope the
new constraint recreating behavior to UNIQUE and PK constraints
(instead of everything that is index-backed). This avoids unwanted
impact on how FKs that reference partitioned tables are handled and
should as a bonus fix the CI.

Thanks,
Álvaro

Attachments:

v2-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patchapplication/octet-stream; name=v2-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patchDownload+55-31
v2-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patchapplication/octet-stream; name=v2-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patchDownload+36-15
v2-0001-Add-regression-test-to-highlight-unexpected-behav.patchapplication/octet-stream; name=v2-0001-Add-regression-test-to-highlight-unexpected-behav.patchDownload+74-1