PostgreSQL查询重写在解析后、规划前通过重写器将视图展开或应用自定义规则，如CREATE RULE实现更新逻辑，转换查询树但不优化性能，影响后续执行计划生成。
PostgreSQL 查询重写是查询处理流程中的关键环节，它在查询解析之后、查询规划之前发生。它的核心任务是根据预定义的规则（rewrite rules），对原始查询语法树进行变换，从而改变其执行方式，而不改变语义。最常见的应用场景是视图展开和条件化查询替换。
查询重写的基本机制
PostgreSQL 使用一个称为“重写器”（Rewrite Engine）的组件来处理 SQL 语句的逻辑转换。这个过程发生在解析器生成查询树（Query Tree）之后，优化器进行计划生成之前。
重写器的核心数据结构是 pg_rewrite 系统表，其中存储了所有用户或系统定义的重写规则。每当执行一个包含规则对象（如视图、带规则的表）的查询时，重写器会查找并应用相关规则。
基本流程如下：
- SQL 被解析为原始查询树（raw parse tree）
- 重写器检查该查询涉及的对象是否有关联的重写规则
- 如果有匹配规则，重写器将原始查询树按照规则定义进行替换或扩展
- 输出一个或多个转换后的查询树，交给后续的查询规划器处理
视图是如何通过重写实现的
视图在 PostgreSQL 中本质上是一条保存的 SELECT 查询，并通过重写规则实现“展开”。当你查询一个视图时，重写器会把对该视图的引用替换成其定义的 SELECT 语句。
例如，创建一个视图：
CREATE VIEW employee_view AS SELECT id, name, department FROM employees WHERE active = true;
当你执行：
SELECT * FROM employee_view WHERE department = 'HR';
重写器会将其重写为：
SELECT id, name, department FROM employees WHERE active = true AND department = 'HR';
这种“视图展开”机制使得视图像虚拟表一样工作，实际查询直接作用于基表，有利于优化器生成更高效的执行计划。
自定义重写规则（CREATE RULE）
PostgreSQL 支持使用 CREATE RULE 定义复杂的重写行为，可用于实现更新视图、日志记录、查询分流等。
例如，实现可更新视图的一种方式：
CREATE RULE employee_view_update AS
ON UPDATE TO employee_view
DO INSTEAD
UPDATE employees SET name = NEW.name, department = NEW.department
WHERE id = OLD.id AND active = true;
这条规则告诉重写器：当用户尝试更新 employee_view 时，不要执行原语句，而是执行指定的 UPDATE 操作到基表。
还可以定义条件规则（使用 WHERE 子句）、多动作规则（DO ALSO），甚至拦截 DELETE 或 INSERT 并转为其他操作。
重写与查询优化的关系
重写阶段不进行性能优化，它只做逻辑等价变换。真正的成本评估和执行计划选择由后续的查询规划器完成。但重写的结果直接影响优化器能看到的查询结构。
比如，一个复杂视图被展开后，优化器可能发现某些连接或过滤可以提前下推，从而提升效率。反之，不当的规则可能导致生成冗余或难以优化的查询结构。
值得注意的是，过度使用 CREATE RULE 可能使查询逻辑变得晦涩，调试困难。现代开发中，常推荐用 INSTEAD OF 触发器替代部分规则功能，以获得更清晰的行为控制。
基本上就这些。PostgreSQL 的重写机制灵活而强大，理解它有助于掌握视图行为、优化复杂查询以及设计高级数据访问层。
