拉迪姆·马雷克：好的CTE，坏的CTE
内容提要
PostgreSQL 12引入了CTE（公用表表达式）的内联优化，改变了CTE的处理方式。CTE根据引用次数和副作用进行处理，单次引用且无副作用的CTE会被内联，从而提高查询性能。物化CTE在多次引用或包含数据修改操作时仍然有用。PostgreSQL 17和18进一步改善了CTE的统计信息传播和内存使用监控，使得CTE的使用更加高效。
关键要点
-
PostgreSQL 12引入了CTE的内联优化，改变了CTE的处理方式。
-
单次引用且无副作用的CTE会被内联，从而提高查询性能。
-
物化CTE在多次引用或包含数据修改操作时仍然有用。
-
PostgreSQL 17和18进一步改善了CTE的统计信息传播和内存使用监控。
-
CTE在PostgreSQL 12之前被视为优化障碍，无法进行索引使用和谓词推送。
-
PostgreSQL 12后，CTE可以根据引用次数和副作用进行内联或物化处理。
-
递归CTE和数据修改CTE始终会被物化，以确保副作用的可预测性。
-
PostgreSQL 17引入了列统计信息传播，改善了物化CTE的估算准确性。
-
CTE的使用应根据具体情况选择内联或物化，以优化性能。
延伸问答
PostgreSQL 12引入的CTE内联优化有什么影响？
PostgreSQL 12引入的CTE内联优化使得单次引用且无副作用的CTE可以被内联，从而提高查询性能，避免了之前CTE作为优化障碍的问题。
什么情况下CTE会被物化？
CTE会在多次引用、包含数据修改操作或使用递归时被物化，以确保副作用的可预测性。
PostgreSQL 17对CTE的改进有哪些？
PostgreSQL 17改善了CTE的统计信息传播和内存使用监控，使得CTE的使用更加高效。
如何选择使用内联还是物化的CTE？
选择内联或物化的CTE应根据具体情况，内联适合单次引用且无副作用的CTE，而物化适合多次引用或需要副作用的CTE。
CTE在PostgreSQL 12之前被视为优化障碍的原因是什么？
在PostgreSQL 12之前，CTE被视为优化障碍，因为规划器无法推送谓词到CTE内部，导致无法利用索引。
递归CTE的处理方式是什么？
递归CTE始终会被物化，以维护迭代过程中的工作表，确保副作用的可预测性。
