PostgreSQL 是否对只读事务进行一些性能优化答案

【问题标题】：Does PostgreSQL run some performance optimizations for read-only transactionsPostgreSQL 是否对只读事务进行一些性能优化
【发布时间】：2015-10-25 17:28:25
【问题描述】：

根据reference documentation，READ ONLY 事务标志除了允许 DEFERRABLE 事务之外还有用吗？

SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY;

DEFERRABLE 事务属性无效，除非事务也是可序列化和只读的。当所有三个这些属性是为交易选择的，交易可能第一次获取快照时阻塞，之后它可以运行没有 SERIALIZABLE 事务的正常开销，也没有参与或被连载取消的任何风险失败。此模式非常适合长时间运行的报告或备份。

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

【问题讨论】：

我的理解是读写事务会带来一些开销，但是在你真正写东西之前你不会产生这个开销。换句话说，就性能而言，READ ONLY 事务应该与只包含读取的READ WRITE 事务相同。这源于 Postgres 处理 XID 分配的方式（有关此 here 的一些信息）。
@NickBarnes 这也符合我的理解。 READ ONLY 确实更安全。
谢谢。因此，可延期交易是当时唯一的实质性优化。
@VladMihalcea 我想知道使用deferrable 提供了哪些实质性优化。文档说“可推迟......可能会在允许继续之前被延迟......一旦开始......它不会产生确保可序列化所需的任何开销；因此序列化代码没有理由强迫它abort ...使此选项适用于长时间运行的只读事务”。不被取消肯定有好处，但是对于reduced serialization overheads，这种潜在的延迟权衡值得吗？不适用于短期查询。
有关信息，如果您使用 JDBC，这是 postgres 驱动程序所做的：github.com/pgjdbc/pgjdbc/blob/REL42.1.4/pgjdbc/src/main/java/…

标签： database postgresql transactions readonly database-concurrency

【解决方案1】：

在问题 cmets 中总结 Nick Barnes 和 Craig Ringer 的 cmets：

READ_ONLY 标志不一定提供任何优化
设置 READ_ONLY 标志的主要好处是确保不会修改任何元组

【讨论】：

另外，postgres 对只读事务的事务 id 进行了优化。 Postgres 提供虚拟交易 id 而不是普通交易 id。它可以提高性能，因为将创建更少的事务 ID，这将加快冻结过程以避免环绕
@AlmasAbdrazak，是的，但是无论事务是否明确设为只读，都会发生优化。碰巧没有进行任何修改的事务也不会生成真实的事务 ID。 postgresql.org/message-id/7011.1286918180@sss.pgh.pa.us
@PaulDraper 我不知道，谢谢参考

【解决方案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.
 */

【讨论】：

您提取的评论属于代码库的一部分，专门用于快照隔离。默认的事务隔离级别是READ COMMITTED，并没有从这个优化中受益。