PostgreSQL 13中分区父表与子表分属不同schema是否会引发性能问题

你所述的分区架构是PostgreSQL 13原生支持的合法部署方式，不存在架构层面的先天性性能问题，可放心使用，仅需注意运维相关的潜在风险即可。

• PostgreSQL的查询规划、执行逻辑不绑定分区的schema归属，分区表的主表、子表分属不同schema不会产生额外的寻址开销，执行计划和同schema下部署的分区表完全一致，性能无差异
• PostgreSQL通过OID直接定位分区对象，schema仅作为逻辑命名空间存在，不会增加查询过程中的CPU、IO消耗，你已完成的功能测试无异常的前提下，性能表现和同schema方案没有区别

• 权限管控风险：访问分区表的角色需要同时持有public schema下主表的操作权限，以及parts schema的USAGE权限、所有分区子表的对应操作权限，新增分区时需同步校验权限配置，避免出现业务侧权限不足报错
• 备份恢复风险：如果采用单schema粒度的备份策略，必须同时备份public schema的主表和parts schema的所有分区子表，单独备份任意一个schema都会导致分区表结构损坏，无法正常恢复
• 运维复杂度提升：默认的元数据查询命令（如psql下的\d）仅展示当前schema的对象，排查分区问题时需要额外指定parts schema查询子表信息，编写运维脚本时也需注意适配跨schema的对象匹配规则

• 可在postgresql.conf中配置search_path = public, parts，减少日常操作时写全schema前缀的工作量
• 自动创建分区的脚本（存储过程、触发器逻辑等）直接指定分区创建到parts schema，避免误创建到其他schema
• 批量配置默认权限，减少后续新增分区的重复授权操作，参考命令如下：

GRANT USAGE ON SCHEMA parts TO 业务访问角色;
GRANT SELECT,INSERT,UPDATE,DELETE ON ALL TABLES IN SCHEMA parts TO 业务访问角色;
ALTER DEFAULT PRIVILEGES IN SCHEMA parts GRANT SELECT,INSERT,UPDATE,DELETE ON TABLES TO 业务访问角色;

内容的提问来源于stack exchange，提问作者Victor Duran