PostgreSQL在与mysql的比较中稍微弱势项：
1.都是堆表，没有所谓的聚集索引表，其实问题不大，聚集索引表也只是在使用聚集索引那些列有加速，而且pg也有聚集索引，只不过要定期重建。
2.mvcc实现，pg是直接在原来page中标记删除、更新行。而mysql的innedb则是像oracle一样，弄了一个垃圾回收区存放这些并发的版本。
1）pg这样做的好处是更新、删除很快，数据恢复也很快。坏处是进行垃圾清理时会扫描page，增加IO消耗，而且在进行垃圾回收时的设置策略需要DBA去设计，较复杂，刚刚使用的人不了解，可能导致autovaccum设置了也不会生效，进而导致垃圾数据的积压。
2）同样是mvcc这种方式，对于高频更新的大表来说，可以在建表的时候设置fillfactor，进而使表的更新发生hot update，在更新时索引不会改变，只是索引指向的ctid重定向到了新行的ctid。这同样是考验DBA的设计能力，初学者在不知道的情况下会觉得更新不但要更新表的tuple，还要更新index的tuple。
那么在mysql中怎么做呢？更新时将旧的行拷贝到垃圾回收区，然后将老行的数据替换为新行数据，索引不用修过。那么数据拷贝的过程也是比较耗时的。
3.正是基于这种mvcc的实现，很多人认为pg不适合做在线事物数据库，这是不合理的。
1）这种实现方式在大表的高频更新时可能会比mysql慢一点，但不存在太大差距。
2）在数据的分析处理上，pg的jion实现则要优于mysql，这也是大家公认pg在替代oracle中优势的地方。
总结：
在线事物上，pg占稍微劣势，但不存在太大差异，90%的应用都感知不到这种差异。
在线分析上，pg占优势，稍微复杂的应用都能感受到。
作为一个混合型数据库需求时，pg完胜mysql。
且pg12将添加新的存储引擎，借鉴innerdb实现方式，这样在OLTP业务上将不再有劣势……，同样，mysql也可以学习pg在企业级应用上的严谨和多表分析上的技术来改进。未来两种数据库将不分高下，都能覆盖大多数应用场景。