在 PostgreSQL 中，“视图（View）”、“连接（Join）”以及“谓词下推（Predicate Pushdown）”是直接影响 SQL 执行性能的重要优化环节。所谓谓词下推，是指优化器能够将外层查询中的 WHERE 条件或 Join 过滤条件，自动下推到视图或子查询内部执行，从而尽可能早地减少参与运算的数据量，降低扫描、排序和连接开销。
近期在一个客户从 Oracle 数据库迁移到 PostgreSQL 系国产数据库的项目中，出现了大量复杂 SQL 性能明显下降的问题。尤其是某套应用系统的开发商，为了简化应用层 SQL 编写，习惯大量创建 View，再通过 View 与其他业务表进行 Join，并在外层追加过滤条件。
在 Oracle 中，由于优化器具备较强的 Query Rewrite 能力，通常可以自动完成：
- View Merge（视图合并）
- Predicate Pushdown（谓词下推）
- Query Elimination（查询消除）
- Join Elimination（连接消除）
因此，即使应用大量使用 View，整体执行性能仍然能够保持较优状态。相关优化参数例如：
_complex_view_merging
_distinct_view_unnesting
_push_join_predicate
_push_join_union_view
_push_join_union_view2
_optimizer_extend_jppd_view_types
_optimizer_order_by_elimination_enabled
_optimizer_ansi_join_lateral_enhance
_optimizer_aggr_groupby_elim
_project_view_columns
_pre_rewrite_push_pred但是oracle的这些优化特性，很多是postgresql或其他数据库都不具备的， 这也是做Oracle替代最难的部分,这也是很多 Oracle 迁移项目中最常见、最典型的性能问题之一。
这套应用最常见的是view + table join , 而在 PostgreSQL 体系中，优化器实现机制与 Oracle 存在明显差异。对于复杂view, 往往无法完成有效的谓词下推，导致执行计划中出现：
- View 先整体展开
- 大量 Seq Scan（全表扫描）
- Join 前无法提前过滤
- 底层索引无法利用
- Hash Join 数据量急剧放大
最终导致 SQL 性能相比 Oracle 出现数量级下降。
场景如：
SELECT a.id
FROM view1 a
JOIN tab2 b ON a.xx = b.xx
WHERE b.name = 'xx';分析思路
1， 先确认是否真的没有谓词下堆
重点看：
- view 内部是不是 Seq Scan
- 是否先全量扫描 view 基表
- join 前有没有过滤
- 是否出现：
Hash Join
-> Seq Scan on big_table2， 为什么 PostgreSQL 不推进
PostgreSQL 对 view 的优化能力其实有限。PostgreSQL 仅在可证明安全的情况下才会将谓词下推到视图中，并且包含某些结构的视图可能会成为优化障碍。以下情况会阻止 predicate pushdown
- view中存在聚合如group by
- view 中存在distinct、limit、 offset
- view中包含union/union all
- view 中有Window function, 如row_number rank
- view 中有left join ,OUTER JOIN
- SECURITY BARRIER VIEW 如CREATE VIEW xxx WITH (security_barrier=true)
优化建议
针对 PostgreSQL 中 View 与复杂 Join 导致的谓词无法下推、索引失效等问题，通常可以从 SQL 改写、索引设计以及执行计划控制等几个方面进行优化。
1. 避免直接 Join View，必要时直接展开 View
对于复杂业务场景，不建议在核心 OLTP SQL 中大量采用 “View + Join” 的写法。尤其当 View 内部已经包含多表关联、聚合、DISTINCT 或 UNION 时，优化器往往难以继续进行谓词下推。
例如：
SELECT a.id
FROM view1 a
JOIN tab2 b
ON a.xx = b.xx
WHERE b.name = 'test';更推荐的方式是直接展开 View 的定义，将过滤条件提前参与关联，使优化器能够更准确地选择执行路径，并充分利用底层索引。
在 PostgreSQL 体系中，复杂 View 更适合作为：
- 报表封装
- 权限隔离
- 数据抽象层
而不适合作为高并发 OLTP 查询入口。
2. 使用 MATERIALIZED VIEW（物化视图）
如果 View 本身逻辑非常复杂，例如包含：
- 聚合计算
- 多表 Join
- 大量 UNION
- 复杂统计逻辑
则可以考虑使用 Materialized View（物化视图）。
物化视图会提前保存计算结果，从而避免每次查询都重新执行复杂逻辑，同时可以单独建立索引。
例如：
CREATE MATERIALIZED VIEW mv_order AS
SELECT ...
FROM ...
GROUP BY ...;并建立索引：
CREATE INDEX idx_mv_order_xx
ON mv_order(xx);需要注意的是，物化视图的数据并非实时更新，需要结合业务场景定期刷新：
REFRESH MATERIALIZED VIEW mv_order;因此更适用于：
- 报表类查询
- 准实时分析
- 夜间批量统计
- 读多写少场景
3. 为 Join / Filter 列建立复合索引
很多 PostgreSQL 性能问题，本质上并非优化器能力不足，而是缺少合理索引。
例如以下 SQL：
WHERE b.name = 'test'
AND a.xx = b.xx推荐建立联合索引：
CREATE INDEX idx_tab2_name_xx ON tab2(name, xx);而不是：
CREATE INDEX idx_tab2_xx_name ON tab2(xx, name);因为 PostgreSQL 会优先利用过滤条件 name 缩小数据范围，再使用 xx 完成 Join。
同时，View 底层涉及 Join 的字段，也必须建立对应索引，否则即使谓词成功下推，也无法真正提升性能。
4. 必要时调整 Join 策略
在部分场景下，PostgreSQL 优化器可能错误估算数据分布，从而选择不合理的 Hash Join 或 Merge Join，导致执行时间急剧增加。
可以临时通过以下参数验证执行计划差异：
SET enable_hashjoin = off;
SET enable_mergejoin = off;此时优化器会倾向使用 Nested Loop + Index Scan。
如果性能明显改善，则通常说明：
- 统计信息不准确
- 数据倾斜严重
- 优化器成本估算偏差
后续可进一步通过：
ANALYZE;或者提高统计信息采样率进行优化。
需要注意，这类参数更适合作为问题定位和 SQL 调优手段，而不建议长期全局关闭。
5. 使用 LATERAL 改写复杂关联
对于部分复杂 View 场景，可以利用 LATERAL 改写 SQL，使 PostgreSQL 更容易采用 Nested Loop + Index Scan 的执行方式。
例如：
SELECT v.id
FROM tab2 b
CROSS JOIN LATERAL (
SELECT *
FROM view1 v
WHERE v.xx = b.xx
) v
WHERE b.name = 'test';这种写法能够让外层表 tab2 的过滤结果优先参与执行，再逐行驱动内部查询，从而避免一次性展开整个 View。
在以下场景中，LATERAL 往往效果明显：
- 外层过滤后数据量很小
- 内层存在高选择性索引
- View 无法有效谓词下推
- Nested Loop 明显优于 Hash Join
在 Oracle 迁移 PostgreSQL 的项目中，LATERAL 也是解决复杂 View 性能问题的一种非常实用的改写手段。
注：PG12+ CTE默认是inline,除非 WITH x AS MATERIALIZED 会阻止优化。
