PostgreSQL 对只读事务是否进行性能优化？

Question

根据参考文档，READ ONLY事务标志除了允许DEFERRABLE事务外还有其他用途吗？

SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;

除非事务也是串行化和只读的，否则DEFERRABLE事务属性没有任何效果。当为事务选择这三个属性时，事务在首次获取其快照时可能会被阻塞，之后它能够运行而不需要SERIALIZABLE事务的正常开销，并且没有对串行化故障产生贡献或被取消的风险。此模式非常适合长时间运行的报告或备份。

数据库引擎是否为只读事务运行其他优化？

- Vlad Mihalcea

---

我的理解是读写事务会带来一些开销，但只有当你实际写入内容时才会产生这种开销。换句话说，在性能方面，一个仅包含读操作的READ WRITE事务应该与一个READ ONLY事务相同。这源于Postgres处理XID分配的方式（有关此信息，请参见此处）。 - Nick Barnes

@NickBarnes 我也是这样理解的。READ ONLY 更多的是一种安全措施。 - Craig Ringer

谢谢。因此，可延迟事务是唯一的实质性优化。 - Vlad Mihalcea

@VladMihalcea 我想知道使用 deferrable 会提供什么实质性的优化。文档中说，“deferrable ... 可以在允许它继续之前被延迟 ... 一旦开始 ... 它不会产生任何确保串行化所需的开销；因此串行化代码将没有理由强制其中止 ... 这使得该选项适用于长时间运行的只读事务”。无疑，不被取消是有好处的，但为了 减少串行化开销 而潜在的延迟是否值得呢？对于短时间运行的查询来说并不值得。 - Davos

如果您使用JDBC，这就是Postgres驱动程序的作用：https://github.com/pgjdbc/pgjdbc/blob/REL42.1.4/pgjdbc/src/main/java/org/postgresql/jdbc/PgConnection.java#L688-L704 - Christophe Roussy

@NickBarnes 我不太明白你所说的关于“只读”和“读写”事务性能如何与Postgres处理XID或提供的链接有关。您能否稍微解释一下或者如果您有任何补充材料，请提供链接？ - AmagicalFishy

Answer 1

总结一下Nick Barnes和Craig Ringer在问题评论中的意见：

1. READ_ONLY标志不一定提供任何优化。
2. 设置READ_ONLY标志的主要好处是确保没有元组会被修改。

- Vlad Mihalcea

---

此外，Postgres 还有一个与只读事务的事务 ID 相关的优化。Postgres 提供虚拟事务 ID 而不是普通的事务 ID。这可以提高性能，因为创建的事务 ID 较少，可以加快冻结过程以避免回绕。 - Almas Abdrazak

@AlmasAbdrazak，是的，但是这种优化无论事务是否显式地设置为只读都会发生。一个没有进行任何修改的事务也不会生成真正的事务ID。https://www.postgresql.org/message-id/[e-mail] - Paul Draper

@PaulDraper 我不知道，谢谢你提供的参考资料。 - Almas Abdrazak

Answer 2

实际上是有影响的。让我引用源代码注释在这里：

/*
 * Check if we have just become "RO-safe". If we have, immediately release
 * all locks as they're not needed anymore. This also resets
 * MySerializableXact, so that subsequent calls to this function can exit
 * quickly.
 *
 * A transaction is flagged as RO_SAFE if all concurrent R/W transactions
 * commit without having conflicts out to an earlier snapshot, thus
 * ensuring that no conflicts are possible for this transaction.
 */

- Yaroslav Schekin

---

你正在提取的注释属于专门用于快照隔离的代码库部分。默认的事务隔离级别是“读已提交”，这不会从此优化中受益。 - num1

@num1 我从未声称过其他（而且问题并没有限制在RC上）。 实际上，它属于可串行化隔离级别（有效地“降低”那些符合条件的事务到RR）。 - undefined