postgresql 15支持创建物化视图时直接指定tablespace，也可用alter table迁移；refresh不改变表空间位置；索引需单独迁移，且须注意锁与i/o共置原则。
物化视图创建时直接指定 TABLESPACE
PostgreSQL 15 支持在 CREATE MATERIALIZED VIEW 语句中用 TABLESPACE 子句指定存储位置，这是最直接、最常用的方式。它和普通表的语法一致，但必须确保目标表空间已存在且 PostgreSQL 用户（通常是 postgres）对该目录有读写权限。
常见错误现象：ERROR: could not set permissions on directory "/path/to/tbs": Permission denied 或 ERROR: tablespace "xxx" does not exist。
- 先确认表空间存在：
\db+或SELECT spcname FROM pg_tablespace; - 路径必须是绝对路径，且目录已由操作系统创建、属主为
postgres、权限至少为700 - 不能使用以
pg_开头的名称（如pg_my_tbs），这是系统保留前缀 - 示例语句：
CREATE MATERIALIZED VIEW mv_sales_summary TABLESPACE fast_ssd AS SELECT ...;
REFRESH MATERIALIZED VIEW 不会改变表空间位置
刷新操作（包括带 CONCURRENTLY 的）只更新数据内容，不移动物理文件。即使你后来把底层表或索引迁到了新表空间，物化视图本身仍留在原 TABLESPACE 中——除非你重建它。
容易踩的坑：误以为 REFRESH 能“同步”到新表空间，结果查询计划里依然走旧磁盘路径，I/O 瓶颈没解决。
-
REFRESH MATERIALIZED VIEW CONCURRENTLY mv_name;不影响表空间 - 想换表空间？只能
DROP后重新CREATE，或用ALTER TABLE ... SET TABLESPACE（见下一条） - 注意：
ALTER TABLE对物化视图有效，因为物化视图在系统层本质是一张带特殊标记的表（relkind = 'm'）
用 ALTER TABLE ... SET TABLESPACE 迁移已有物化视图
PostgreSQL 允许对物化视图执行 ALTER TABLE 命令来变更其表空间，这是迁移存量物化视图的推荐方式，无需重建、不丢失依赖（比如视图、函数引用）。
关键限制：该操作会获取 ACCESS EXCLUSIVE 锁，期间所有对物化视图的读写都会被阻塞。如果物化视图很大，迁移耗时可能较长。
- 语法就是普通表迁移：
ALTER TABLE mv_name SET TABLESPACE new_tbs; - 执行前建议先查当前位置：
SELECT relname, spcname FROM pg_class c JOIN pg_tablespace t ON c.reltablespace = t.oid WHERE c.relname = 'mv_name'; - 迁移后，其关联的唯一索引（如用于
CONCURRENTLY刷新的索引）**不会自动迁移**，需单独处理：ALTER INDEX idx_mv_name SET TABLESPACE new_tbs; - 若物化视图无唯一索引，
CONCURRENTLY刷新将失败，迁移后务必检查并补建
表空间选择对物化视图性能的实际影响
把物化视图放到 SSD 表空间（如 fast_ssd）不一定总能提升查询速度。真正起作用的是访问模式与存储介质特性的匹配程度。
例如：一个每天只被报表作业扫描一次的物化视图，放在 HDD 表空间反而更省成本；而一个被高频 JOIN 的物化视图，若和关联表不在同一表空间，跨磁盘 I/O 可能成为瓶颈。
- 优先考虑「共置原则」：物化视图 + 它常 JOIN 的表 + 相关索引 → 尽量放在同一高性能表空间
- 避免把物化视图和它的源表（尤其是远程 FDW 表）放在同一表空间——它们访问压力类型不同，混放易相互干扰
-
pg_matviews不记录表空间信息，得查pg_class和pg_tablespace关联；\d+ mv_name命令末尾会明确显示Tablespace行
真正要小心的是迁移过程中的锁和索引脱节——物化视图看起来像视图，行为却更接近表，很多 DBA 在第一次用 ALTER TABLE ... SET TABLESPACE 移它时，才发现唯一索引还钉在旧磁盘上。
