三、我的评价
PostgreSQL与InnoDB的多版本实现最大的区别在于最新版本和历史版本是否分离存储，PostgreSQL不分，InnoDB分。
PostgreSQL 的这种设计被其最初的设计者Mike Stonebraker称为no-overwrite的设计，在设计了PostgreSQL几年之后他的一篇回顾性论文《The Implementation of Postgres》(PostgreSQL早期叫Postgres)中，Stonebraker指出当初这样设计的主要原因是寻求与当时已经广泛使用的WAL模式不同的存储 机制，有点为了创新而创新的意思。这一设计有两大好处：一是事务回滚时无需复杂处理，非常快;二是可以查询以前的历史数据。还有一个可能的好处是可以实现数据即日志，即更新时只要更新数据就行了，不需要再写日志来描述做了什么更新。但要使这个好处实现，需要有一种持久的，并且随机写具有与顺序写类似性能的 存储介质才行，因为为了保证事务提交后的持久性，需要写出被事务更新的数据，而这些数据可能是离散的。WAL系统则不同，事务提交时只需要写日志就行了， 而日志是顺序写入的。当前的硬件环境并不是这样，因此PostgreSQL中仍然还要写日志，只不过不需要写UNDO日志，只要REDO日志就行了。
最新的PostgreSQL与当初Stonebraker的设计已经有了很大改进，比如HOT技术减少了索引中的版本数，Visibility Map技术加快了VACUUM，记录头部结构也更紧凑。但no-overwrite的设计原则仍然没变。相对于InnoDB，PostgreSQL的优势似乎主要的只有一条：事务回滚可以立即完成，无论事务进行了多少操作。查询以前的历史数据的功能并不常用，在目前的PostgreSQL中也并不实用。
PostgreSQL的主要劣势在于：
最新版本和历史版本不分离存储，导致清理老旧版本需要作更多的扫描，代价更大;
UPDATE不是本地更新，会产生老旧版本需要清理。与之相对的是InnoDB只有在事务回滚时才需要清理老的记录数据。而事务回滚是罕见的;
只要有一个索引属性被更新，或者新版本的记录与原版本不在同一页面，就要插入所有索引的新版本索引项;
堆占用的空间不能通过在线的VACUUM回收，在线VACUUM会产生很多碎片(这也是由于使用了堆而不是索引组织表导致的);
由于索引中完全没有版本信息，不能实现Coverage index scan，即查询只扫描索引，直接从索引中返回所需的属性。与之相对的是InnoDB中二级索引页头记录的最近修改该页的事务ID信息可以在大部分情况下 实现Coverage index scan。Coverage index scan是应用中经常使用的优化技巧，PostgreSQL不支持这个对提升系统性能带来很大限制，因为索引扫描是顺序访问，去访问堆则很可能变成乱序访问，性能可能相差百倍;
判断版本可见性更复杂，开销更大。PostgreSQL比InnoDB在判断可见性时，需要增加访问事务提交日志的操 作，事务提交日志每个事务需要分配两个bit，对高更新负载的系统会占用较大空间，这时要么事务提交日志回占用大量内存，要么判断可见性时就可能产生额外 的IO。对比PostgreSQL中判断可见性的函数HeapTupleSatisfiesMVCC和InnoDB中判断可见性的函数read_view_sees_trx_id，可以容易看出这两者的复杂度不可同日而语。
InnoDB的主要劣势在于事务回滚时需要清理事务所作的所有修改，因此使用InnoDB时要避免使用超大型事务，否则回滚可能超慢无比。
