本节书摘来自异步社区出版社《PostgreSQL 9.0性能调校》一书中的第1章，第1.1节，作者： 【美】Gregory Smith，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.1 PostgreSQL历史版本的性能
2005年11月，PostgreSQL发布了其8.1版本。该版本中包含了众多内部结构的改进，其中一些期望能够提高多个活动客户端在多处理器系统下的数据库性能。其结果是在处理沉重工作负荷时，数据库能力得到成比例的提高。在如今的硬件设备上进行的基准评测，突出地显示了其对先前版本的跨越。可以在http://suckit.blog.hu/2009/09/29/postgresql_history看到György Vilmos 对8.0版至8.4版的性能横向比较。它准确地显示了性能显著提升的程度。这些测试使用由http://sysbench. sourceforge.net/网站提供的sysBench基准评测软件的联机事务处理（OLTP）测试工具。
这个测试给出了每秒处理事务数（TPS, Transactions Per Second）系统整体速度的数据值，可以在只读模式下或包含写入的模式下运行。在只读模式下，从8.0版本升级到8.1版本的性能提升4倍，而8.3版本的性能提升则再提高2倍左右。如表1-1所示。
在负载峰值情况下客户端数量的上升给出了数据库内部处理访问共享资源程度大小的一种思路。特别是8.1系列版本当中包含了一些重大的升级。而在写入模式下的性能改进与此类似，8.0版本到8.3版本之间性能几乎达到了8倍的增益，见表1-2。
在这些测试当中可以看出8.3版本到8.4版本性能有略微的降低，这是由于对数据库进行了细微的重新调整，以改善其在最糟糕情况下的性能。8.4版本中采集了更多的统计数据用于提高复杂索引的性能，并在测试中牺牲了部分不太重要排序的速度。第10章将会讲述更多关于这方面的详细内容。
尽管结果不会涵盖如此广泛的版本，但其他的测试结果也证实了性能的提升。可以很容易地看出，在2005年年底之前8.1版本交付的时候，之前所达成的关于PostgreSQL性能的结论是完全过时的。2008年8.3版本发布的时候，速度提升可以算是一个很大的飞跃。因此，8.3之前的版本并不能代表目前的性能，同时首选使用这个版本或者后续版本还有很多其他的原因。
1.1.1 选择部署的版本
如果用户有较老版本的PostgreSQL系统，并想让它运行得更快一些，因为新版本的这些令人瞩目的特性，首要的事情不是考虑如何调整设置，而是应该考虑升级到最新版本的可能性。如果用户正在实施一个新的项目，用户可以考虑最新的8.3版本。除了性能提升外，该版本还有一些影响到应用程序编码变化，用户可以更容易开始项目的实施，避免后期的改进。
第16章包含一个参考指南，其内容为从8.1版本至9.0版本当中每个主要的PostgreSQL版本所加入的与性能相关功能的介绍。用户可能会发现只有在最新版本里的功能能够引起他们的注意，因此强烈建议用户使用最新的版本。在本书中将会突出这些特定版本的变化。
1.1.2 升级到更新的主要版本
目前为止，从现有的PostgreSQL版本升级（例如从8.1.X版本升级到8.2.X版本）到最新的主要版本的惟一方法是dump转储和重载。使用新版本中的pg_dump和/或pg_dumpall程序将整个数据库的内容写入一个文件。采用这样的方法，如果有任何变更需要进行更新，那新的转储程序可以尝试处理它们。并不是所有的升级变更都会自动进行。随后，根据用户要转储的格式，可以运行它所生成的脚本或者是使用pg_restore程序来处理这个任务。pg_restore是在新版本的PostgreSQL中的一个较好的替代方案，具有并行存储的功能。
图标
如果用户正在使用的操作系统并不允许用户在同一时间内运行多个PostgreSQL版本，例如现行的RedHat Linux的RPM包，在同一时间内同时安装一个老的PostgreSQL版本和一个新的PostgreSQL版本是很困难的。在PostgreSQL 9.0中，对这种情况所做的一些改进也在开发当中。因此在进行升级规划时，要将确认运行多个版本的可行性作为其中的一个部分。
转储数据需要一定的时间，恢复数据要花的时间更久。在这种情况下，数据库可能要暂停服务，这样才能保证没有其他的任何更改被写入到转储文件中。对于大型的数据库，停机的时间可能会很长而且是让人无法接受的。
在一些要求较高的环境中，数据库要求宕机时间为0，以达到7×24小时运行。在这种情况下，转储和重载是不适用的。直到最近，针对这种环境使用所进行的PostgreSQL升级，惟一有效的方法是Slony的复制。Slony是最受欢迎的解决方案，第14章有其更详细的介绍。Slony当中的一个功能就是用户可以不在所要进行复制的所有节点都运行相同版本的PostgreSQL。用户可以提取一个新的节点来运行新版本的PostgreSQL，等待复制完毕后，一旦与源相匹配，那么将其进行切换。
现在，有一种新方法可以不需要任何的复制软件，该程序起初称为pg_migrator（见http://pgfoundry.org/projects/pg-migrator/），可以不需要转储和重载操作来完成从8.3版本到8.4版本的升级。这个过程称为就地升级（in-place upgrading）。用户需要进行仔细的测试，在PostgreSQL的功能中既有已知的限制也有一些未知的不太受欢迎的相关特性。要确保仔细阅读升级工具的文档。从PostgreSQL 9.0开始，这个模块包含在核心数据库中，并且名称更改为pg_upgrade。由于所有就地升级都会有些风险并需要进行仔细的测试，因此在很多情况下，pg_upgrade可以带用户从8.3版本或8.4版本升级到9.0或更高的版本。
PostgreSQL开发社区目前决定将就地升级功能应用于未来的版本中。现在，TB以及更大数据量规模的PostgreSQL的安装已经很普遍，因此升级时只使用转储和重载是不实际的。
1．从更早的版本升级到PostgreSQL 8.3+
8.3版本的主要内部变化是从更早版本进行升级当中不需要转储整个数据库并进行重载到更新的版本。这让8.3版本成为其发展史上的重要里程碑。与8.2版本相比较，不仅仅速度上快很多，一旦用户使用了8.3版本，从此就可以使用就地升级功能了。
从早期版本升级到PostgreSQL8.3或后续版本是比较困难的。部分较老的应用程序依赖于非字符型数据类型，被透明转换成TEXT类型，因为多种原因，这个特性在8.3版本中被删除，更多信息请浏览http://www.postgresql.org/docs/8.3/static/release-8-3.html。
虽然升级数据库版本总是有可能会引入新的问题，尤其是对早期版本编写的应用程序升级到8.3版本或更高版本时。这也许可通过手动添加回被删除的自动类型转换功能来有解决这个问题。在http://petereisentraut.blogspot.com/2008/03/readding-implicit-casts-in-postgresql.html有一个具体的实例。然而在应用程序中固化这个特性的替代方法是使用更强大和可持续的方法。较老的特性因为其会导致莫名其妙的应用程序问题而被取消。如果用户将其添加回来，就需要对每一个新的PostgreSQL版本做其他额外的添加步骤。关于这个主题和执行主要版本的PostgreSQL升级会遇到的问题，可以浏览http://blog.endpoint.com/2010/01/postgres-upgrades-ten-problems-and.html以获取更多信息。
2．次要版本的升级
从8.4.1版本升级到8.4.2版本之类次要版本升级不需要使用转储/重载或使用类似pg_ upgrade的工具。只需要停止服务器，安装新版本，然后对现有的服务器数据文件运行新的数据库二进制更新。部分用户不愿意进行此类升级，以免数据库内的改动会让正在运行的程序产生问题。在PostgreSQL中不会产生这种情况。PostgreSQL项目的规则在http://www.post gresql.org/support/versioning描述得很清楚。
虽然升级多少都会有些风险，PostgreSQL次要版本仅修复经常碰到的安全性和数据损坏错误，以减少升级的风险。PostgreSQL社区认为不升级比升级的风险高。
在PostgreSQL次要版本升级当中，永远不会找到会破坏应用程序的任何一种不可预期的修改。漏洞、安全和损坏性修复总会以一种最小化引入外部可视的行为变化几率的方式被执行。如果是无法避免的话，那么将会在发行说明当中详细地去解释其中的原因以及建议的解决方案。在其中将会发现一些细微的问题，这是由于某些已解决的缺陷所带来的，这甚至会在一个次要版本的更新之后得到彻底解决。从PostgreSQL邮件列表当中不难发现某个问题的报告已经在兼容该版本的一些最新的次要版本更新当中被解决，因此升级到该版本是使所有这些问题消失的主要需求。
