Re: Unexpected reindex when altering column types for partitioned tables - Mailing list pgsql-hackers

From Álvaro Rodríguez
Subject Re: Unexpected reindex when altering column types for partitioned tables
Date
Msg-id CA+C_kKX9Qk0JQZ+bjyHWNiCBLYN4kyCRdJoJ+gtr1K2+Xjo55g@mail.gmail.com
Whole thread
In response to Re: Unexpected reindex when altering column types for partitioned tables  (Álvaro Rodríguez <alvaro@datadoghq.com>)
List 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

pgsql-hackers by date:

Previous
From: Vaibhav Dalvi
Date:
Subject: Re: gist_trgm_ops '=' operator: planner picks it over btree, ~300x slower
Next
From: Andrei Lepikhov
Date:
Subject: Re: hashjoins vs. Bloom filters (yet again)