亚历山大·科罗特科夫：为什么PostgreSQL需要更好的替代表引擎API？
内容提要
PostgreSQL的索引访问方法API存在已久，但缺乏完整的事务存储引擎。现有设计限制了灵活性，需求包括替代MVCC实现和非堆存储。建议将索引AM分为逻辑层和实现层，以支持多样化存储模型，减少写放大，提高性能。
关键要点
-
PostgreSQL的索引访问方法API（AM）已经存在很长时间，但缺乏完整的事务存储引擎。
-
现有设计限制了灵活性，需求包括替代MVCC实现和非堆存储。
-
建议将索引AM分为逻辑层和实现层，以支持多样化存储模型。
-
替代MVCC实现的需求包括基于UNDO日志的存储和非堆存储。
-
当前的表AM和索引AM API紧密耦合，导致实现上的问题。
-
现有的更新机制导致写放大，更新一个索引属性需要在每个索引中插入。
-
缺乏“点删除”方法，导致删除效率低下。
-
索引当前通过块号和偏移号引用表行，限制了存储额外负载的能力。
-
提议的解决方案包括允许索引AM存储自定义负载和实现“点删除”方法。
-
建议的分层设计将逻辑索引AM与索引AM实现分开，以便更好地支持未来的存储模型和MVCC实现。
-
这种新架构可以减少写放大，提高系统性能，支持多样化的存储模型。
延伸解读
PostgreSQL的灵活性与局限性
尽管PostgreSQL的索引访问方法API已经存在多年，但其设计的局限性仍然显著。当前的MVCC实现和索引结构紧密耦合，导致灵活性不足，无法满足多样化存储需求。理解这些局限性有助于开发者在选择数据库解决方案时做出更明智的决策。
未来存储模型的支持
文章提出将索引AM分为逻辑层和实现层的建议，旨在支持未来的存储模型。这种分层设计不仅可以减少写放大，还能提高系统性能。开发者应关注这一变化如何影响现有数据库架构的兼容性和扩展性。
替代MVCC实现的必要性
当前的MVCC实现存在写放大的问题，更新一个索引属性需要在每个索引中插入。文章提到的基于UNDO日志的存储方案，可能为解决这一问题提供新的思路。开发者在考虑数据库性能时，应关注替代MVCC实现的潜在优势。
延伸问答
PostgreSQL的索引访问方法API存在哪些主要问题？
PostgreSQL的索引访问方法API缺乏完整的事务存储引擎，现有设计限制了灵活性，导致写放大和删除效率低下等问题。
为什么需要替代MVCC实现？
替代MVCC实现可以通过基于UNDO日志的存储来提高灵活性，解决现有MVCC模型的局限性，减少写放大。
如何改善PostgreSQL的索引访问方法API？
建议将索引AM分为逻辑层和实现层，以支持多样化存储模型，减少写放大，提高性能。
当前PostgreSQL索引API的更新机制有什么缺陷？
当前的更新机制导致写放大，更新一个索引属性需要在每个索引中插入，效率低下。
什么是“点删除”方法，它有什么作用？
“点删除”方法允许高效删除特定元组，避免当前方法的低效率，提升删除操作的性能。
分层设计对PostgreSQL索引API的影响是什么？
分层设计将逻辑索引AM与实现分开，有助于支持未来的存储模型和MVCC实现，提高系统的灵活性和性能。
