我在PostgreSQL中观察到，当把 varchar 列的长度提高时，非分区表与分区表之间的行为有所不同。

对于 non‑partitioned tables，扩大 varchar 的长度限制似乎只是一次轻量级的元数据变更：它几乎可以立即执行，现有索引保持不变——它们的物理存储 (relfilenode) 也未改变。

test=# create table t(a varchar(10));
CREATE TABLE
test=# create index t_idx on t(a);
CREATE INDEX
test=# select relfilenode from pg_class where oid = 't_idx'::regclass;
 relfilenode
-------------
       18889
(1 row)

test=# alter table t alter COLUMN a type varchar(20);
ALTER TABLE
test=# select relfilenode from pg_class where oid = 't_idx'::regclass;
 relfilenode
-------------
       18889
(1 row)

然而，对于 partitioned tables，情况却不同。当我对属于分区表的 varchar 列执行相同的修改时，每个分区的索引都会被重新构建。relfilenode 的变化表明创建了一个新的索引文件。

test=# create table p(a int, b varchar(10)) partition by range (a);
CREATE TABLE
test=# create table p1 partition of p for values from (0) to (10);
CREATE TABLE
test=# create index p_idx on p(b);
CREATE INDEX
test=# select relfilenode from pg_class where oid = 'p1_b_idx'::regclass;
 relfilenode
-------------
       18906
(1 row)

test=# alter table p alter COLUMN b type varchar(20);
ALTER TABLE
test=# select relfilenode from pg_class where oid = 'p1_b_idx'::regclass;
 relfilenode
-------------
       18908
(1 row)

在生产环境中，对大型分区表进行索引重建可能会长期阻塞业务。

• 为什么PostgreSQL会对分区表实现这种行为？
• 是否有办法在此类场景中优化或避免索引重建？

解决方案

分区索引的重建是由提交c01eb619a83a引入的，用以修复这里报告的问题：https://www.postgresql.org/message-id/[email protected]

根据提交信息，社区本来打算在未来解决分区索引重建的问题，但到目前为止还没有取得进展。