Re: Unexpected reindex when altering column types for partitioned tables

From: Álvaro Rodríguez <alvaro(at)datadoghq(dot)com>
To: Alberto Piai <alberto(dot)piai(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: Unexpected reindex when altering column types for partitioned tables
Date: 2026-10-06 11:23:18
Message-ID: CA+C_kKX9Qk0JQZ+bjyHWNiCBLYN4kyCRdJoJ+gtr1K2+Xjo55g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I have a new version of the patch with the following changes:
- The child table recursion now adds children to the queue in
reverse-BFS order (so lowest level first). However, the root table is
added to the work queue elsewhere, which means it is still first.
- We keep the two passes: one of them will do all child indexes (which
will be processed in the same reverse-BFS order), and the next one
will do the root indexes only. This means that everything is processed
in the right order.
- Tests are added to validate that this works on 2-level partitioned tables.

The solution works, but I'm not sure it's final. Ideally we would be
able to move the root table in the work queue to appear after all the
child tables. In that way, we would process everything in the right
order and we wouldn't need the two separate passes. But I'm trying to
figure out where to do so and whether it's safe, since we can't really
delay adding the table to the work queue, but it also seems like a bad
idea to play with the order after creation. The solution above might
be the right balance here.

Additionally, the patch relies on find_all_inheritors() from
pg_inherits.c to return everything in BFS order. This seems to be the
case but isn't documented. The discussion in thread [1] may be
relevant for this, and indeed if that ends up merged, we might want to
use their find_all_inheritors_ordered() function to avoid any trouble
here.

Re thread [0], I have been doing some testing, I will post something
there to figure out if we can combine the two patches!

Best,
Álvaro

[0] https://www.postgresql.org/message-id/flat/DB533C25-C6BA-4C0F-8046-96168E9CDD72%40gmail.com
[1] https://www.postgresql.org/message-id/flat/57100518-3FF1-48AD-B550-47B9A3E88688%40gmail.com

Attachment Content-Type Size
v5-0001-Add-regression-test-to-highlight-unexpected-behav.patch application/octet-stream 7.4 KB
v5-0003-Skip-index-rewriting-for-PK-associated-indexes-wh.patch application/octet-stream 6.8 KB
v5-0002-Skip-index-rewriting-when-possible-on-ALTER-TABLE.patch application/octet-stream 13.4 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrei Lepikhov 2026-10-06 11:26:48 Re: hashjoins vs. Bloom filters (yet again)
Previous Message Vaibhav Dalvi 2026-10-06 11:02:33 Re: gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower