PostgreSQL's MVCC is bad. So is everyone else's
a day ago
- PostgreSQL的MVCC将旧行版本存储在表本身中，导致膨胀、写放大以及依赖VACUUM进行清理。
- 替代的MVCC设计（Oracle/InnoDB、SQL Server、MongoDB、基于LSM的数据库）将成本转移到撤销日志、tempdb、缓存或压缩中，并具有各自的故障模式，如快照过旧错误、回滚开销或实例范围的停顿。
- 所有MVCC系统都面临相同的基本矛盾：它们必须选择如何处理版本存储、索引、清理和长时间运行的事务，没有一种设计能消除所有成本——它们只是将成本在写入者、读取者、后台进程或存储组件之间转移。
- PostgreSQL基于堆的MVCC提供零成本的回滚且从不取消读取者，但使得垃圾可见并需操作员驱动，这与基于撤销的引擎形成对比，后者对写入和历史读取施加成本。
- 替换PostgreSQL MVCC（zheap、OrioleDB）的努力正在进行中，但面临重大的工程挑战，因为堆的简单性是系统的基础。