PostgreSQL 无真正可用的“MATERIALIZED CTE”：15及之前报错，16+中MATERIALIZED仅为语法占位符，不改变执行行为；优化器自主决定是否物化，与关键字无关。
PostgreSQL 没有真正可用的 “MATERIALIZED CTE” —— 在 15 及更早版本中加 MATERIALIZED 会直接报错；16+ 虽然语法通过，但该关键字被完全忽略，不改变任何执行行为。
为什么 WITH MATERIALIZED cte AS 不起作用
PostgreSQL 的 WITH 子句从不提供用户可控的物化开关。所谓 “MATERIALIZED” 关键字在 16+ 中仅是语法占位符，优化器不会据此生成临时表或预留内存。你看到的执行计划里依然可能是内联展开、重复计算，或随机选择物化——全由优化器自主决定，和你写不写 MATERIALIZED 无关。
常见错误现象：ERROR: syntax error at or near "MATERIALIZED"（v15 及之前）、或执行计划毫无变化（v16+）。根源是把 Oracle 的 /*+ MATERIALIZE */ 或 SQL Server 的 hint 误迁移到 PostgreSQL。
- PostgreSQL 12 引入的是
NOT MATERIALIZED和显式MATERIALIZED两个提示，但仅用于影响“是否允许外层条件下推”，不是控制“是否缓存结果” -
NOT MATERIALIZED的真实作用：让优化器把 CTE 当作视图重写，从而把WHERE条件下推进子查询（可能触发索引扫描） -
MATERIALIZED的真实作用：强制物化该 CTE，防止条件下推——适用于“必须确保子查询只算一次且结果严格一致”的场景（如含random()或多次引用高代价函数）
真正能“强制缓存中间结果”的三个可行方案
当 EXPLAIN ANALYZE 显示某段子查询被反复执行（例如多个 SubPlan 节点 time/rows 高度重复），且它本身开销大、结果稳定，才值得干预。绕过 CTE 的限制，用以下方式：
-
CREATE TEMP TABLE AS SELECT ...：单会话内最直接的“手动物化”。后续所有SELECT都可FROM temp_table，还能加索引。会话结束自动销毁 -
CREATE MATERIALIZED VIEW AS SELECT ...：跨会话复用。但必须确保基表有主键或唯一索引，否则REFRESH MATERIALIZED VIEW CONCURRENTLY会失败 - 拆成两步查询：先
WITH cte AS (...) SELECT * INTO TEMP my_temp FROM cte，再查my_temp。效果同第一种，但更显式
别用 WITH RECURSIVE 模拟缓存——它只解决树形遍历，不通用；也别指望 work_mem 调大就能让 CTE “稳住”中间结果——超限时 PostgreSQL 会自动落盘排序/哈希，反而更慢。
什么时候该放弃“缓存”，直接重写逻辑
多数性能问题根本不在“要不要缓存”，而在原始写法阻碍了优化器。先看 EXPLAIN ANALYZE 输出信号：
- 出现多个
SubPlan且actual rows值巨大 → 真的在重复执行，需干预 - CTE 内部有
ORDER BY ... LIMIT 1却被用在SELECT列 → 改用DISTINCT ON或ROW_NUMBER() OVER () = 1 - 外层
WHERE条件没进 CTE 的WHERE，导致 CTE 返回百万行再过滤 → 把条件挪进去，或改用JOIN - 多个
UNNEST+LATERAL但数组长度差异极大 → 考虑预聚合或分批次处理
CTE 的核心价值从来不是性能加速，而是逻辑分层与调试便利——每层都能单独执行 SELECT * FROM cte_name 验证数据，这点子查询做不到。但一旦你开始为性能硬加 MATERIALIZED，大概率说明该换思路了。
