作者：（美）艾博拉·艾哈迈德（Ibrar Ahmed）,格利高里·史密斯（Gregory Smith）,范翊
出版社：机械工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
PostgreSQL 9X之巅(原书第2版)试读：
前言
、第1～5章的翻译。彭煜玮，武汉大学副教授、硕士生导师，长期从事数据管理技术的教学和研究。著有《PostgreSQL数据库内核分析》一书。独立完成了PostgreSQL 9.3.4、9.4.4、9.5.0、9.6.0的文档翻译工作，并无偿捐献给社区。现任PostgreSQL中国用户协会常务委员、中国计算机学会数据库专业委员会委员、ACM SIGMOD中国分部委员。主要负责第9、10、12章的翻译。
唐成，杭州乘数科技有限公司CTO，《PostgreSQL修炼之道：从小工到专家》作者，专注于PostgreSQL数据库和Greenplum数据库领域，历任网易开发专家、阿里巴巴高级数据库专家。主要负责第6～8章和第15章的翻译。
黄坚，湖南红手指信息技术有限公CTO，从2011年开始，积极参与PostgreSQL数据库在国内的推广，是pgpool-II中文手册的维护者之一，《PostgreSQL 9Administration Cookbook》的主要译者，常用网名：洞庭湖的泥鳅和Bambo。主要负责第11、16章的翻译。
郭凯，PostgreSQL社区志愿者，硕士期间曾从事PostgreSQL内核代码分析与研究。主要负责第13章的翻译。
王鹏，2013年6月毕业于南京大学，现就职于核工业北京地质研究院，主要从事多源地学信息数据集成与开发工作。主要负责第17章的翻译。
李飞，西安交通大学网络信息中心教师、资深软件工程师，热爱编程，自2003年开始使用PostgreSQL，JFinal、Zbus等项目的贡献者。主要负责第14章的翻译。
杜金房，系统管理员/DBA/架构师、FreeSWITCH中文社区创始人、《FreeSWITCH权威指南》作者、FreeSWITCH开源项目核心贡献者（Committer），精通PostgreSQL架构设计和优化技术。主要负责第18章的翻译。
周宝峰，瀚高软件北美研发中心总经理，致力于国际合作。与本书作者进行了深入的沟通，并在翻译的整体审校方面付出了极大心血。
王硕，专注于PostgreSQL内核开发7年，致力于成为PostgreSQL数据库知识的布道者，并为国产基础软件添砖加瓦。
田兵，数据库内核开发工程师，长期从事PostgreSQL内核开发工作。
韩悦悦，文档工程师，PostgreSQL官方文档多个版本的中文翻译者。
李晓飞，测试工程师，电信行业外企工作10年，现就职于瀚高软件。
孙彪，数据库开发新生力量，目前正在系统学习PostgreSQL相关知识。
李鹏，数据库内核开发工程师，任何与PG内核开发相关的话题，欢迎与我交流讨论：sirlipeng@gmail.com。
王明军，开发工程师，喜欢编程和猫，希望世界和平。
贺冬，数据库DBA。每个人对原文的理解可能都不太相同，欢迎给我发邮件一起探讨：hedongfrank@163.com。
王刚，研究生接触到数据库底层知识，后参与数据库内核开发，喜欢探究底层机制，喜欢自由。
李冉，新晋开发工程师，协助此次翻译的审校工作。中文版序
When I decided to write the second edition of this book，the soul purpose was to target the middle to experience level users，developers and database administrator of PostgreSQL.As the title suggest，？this book is about performance tunning and database optimization therefore some PostgreSQL knowledge is required to understand the book.I have tried to cover the basic to advance level concept of database and database performance.It also includes the very new PostgreSQL performance features.
After getting the very good response from the readers，I have enhanced the second edition by adding more practical oriented examples.This edition is getting very good response from the readers.
A really good response from readers in terms of revenue，sale and Chinese translation the major goal is met.The book lakes in way that it is hard for basic users，but no book is good for everyone.This is my second book，my first book PostgreSQL Developer's Guide covers the basics concepts of PostgreSQL，therefore this make a really good combo.
The book is also written by Gregory Smith，and he did really tremendous job to make that book a success.This is his effort，that this book will get very huge audience in China.As I have mentioned，this is my second book and both the books are with Packt publications.I really want to acknowledge the Packt publication for their reviewers，which were part of that project.
I am really happy for the translation of the book in China，and hope it will help the Chinese people to understand the mid to advance level concepts of PostgreSQL optimizations.
I don't know about anything about the Chinese language，therefore without PostgreSQL association who initiated this project and the China’s PostgreSQL community；it won’t be possible.Hope this will be a good contribution of PostgreSQL association for the Chinese people.
当我决定写作本书第2版时，主要目标是面向中高级的PostgreSQL用户、开发人员和DBA。正如这本书的英文版书名，这本书是关于性能调优和数据库优化的，因此读者需要具备一些PostgreSQL知识才能理解。我努力在书中涵盖数据库及其性能从初级到高级的内容。同时本书也包含了新引入的PostgreSQL性能相关特性。
在得到读者的反馈后，我加入了更多实用的例子来加强第2版。这个版本在读者中日益收到良好的回应。
读者的好评体现在书的收益、销售和中文版翻译方面，主要目标得以实现。本书的内容对初级用户来说是有难度的，但没有一本书能够适合所有不同水平的读者。这是我的第二本书，我的第一本书《PostgreSQL Developer’s Guide》涵盖了PostgreSQL的基本概念，两本书一起结合阅读应该是一个非常好的组合。
这本书是由我和Gregory Smith共同编写的，他做了很多非比寻常的工作来使这本书获得成功。也正是他的努力，这本书会在中国有非常多的读者。正如我所提到的，这是我的第二本书，这两本书都是在Packt出版的。我非常感激Packt出版社的审校人员，本书的成功也有他们的一份功劳。
我非常高兴这本书能在中国翻译出版，并且希望它能帮助中国的读者理解PostgreSQL优化的中高级概念。
我本人是丝毫不懂中文的，没有发起翻译工作的中国PostgreSQL协会以及中国的PostgreSQL社区，本书的中文版是不可能发行的，也希望本书中文版能成为PostgreSQL协会对中文读者做出的一个很好的贡献。——Ibrar Ahmed关于作者
艾博拉·艾哈迈德（Ibrar Ahmed）是一家企业级PostgreSQL公司的高级数据库系统架构师。在从事开源开发之前，主要从事软件和嵌入式系统的开发工作，他也拥有大量的开源软件的开发经验。他是PostgreSQL社区的贡献者之一，同时也是其他开源社区的贡献者，比如谷歌的Chromium项目。他是一位开源软件的传播者，对开源开发的热情使得他为不同的开源社区贡献了数个意义非凡的特性。
艾博拉为了使PostgreSQL成为一个复合的关系型数据库做出了重要的贡献。他开发维护了多个PostgreSQL的扩展，用于与其他关系数据库交换数据，例如：MySQL、NoSQL数据库、MongoDB和并行文件系统存储（如HDFS）。他还出版了另外一本书《PostgreSQL Developer’s Guide》，由Packt Publishing出版。
格利高里·史密斯（Gregory Smith）是南卡罗来纳州查尔斯顿的一位主要的PostgreSQL传播者，就职于Crunchy Data Solutions公司。他为制造业、金融和网络开发等行业的客户提供数据库咨询服务已经有20年之久了。
撰写本书是他讲授数据库性能调优方面的第二次尝试。他曾在1995年撰写了一本叫作《Progress Performance FAQ》的小型免费电子书，内容涵盖了如何使Progress 4GL及其相关的数据库运行得更快。在2001年，他转而专门使用PostgreSQL 7.0开发项目，从那时候起，他就开始关注PostgreSQL每个发行版本所能解决问题的复杂程度。
从PostgreSQL 8.3开始，Gregory对每个后来发行的PostgreSQL版本都做出了贡献，增加了一些额外功能。他同时为PostgreSQL编写了一系列附加工具集，这些工具包括pgtune、pgbench-tools、peg和2warm等。关于审校者
丹尼尔·杜兰特（Daniel Durante）在不写程序的时候热衷于烘焙、品尝咖啡、骑摩托车、射箭、焊接和做木工。他从12岁就开始使用PHP、Node.js、Golang、Rust和C语言来编写网络和嵌入式程序。
他曾经开发了一款基于文本的浏览器游戏，已经有1000000个活跃玩家，为CNC机床开发一个装箱问题（Bin-Packing）算法，并贡献了一个最古老的Node.js的ORM——Sequelize.js。
他还帮助审阅了Packt出版社出版的《PostgreSQL Developer’s Guide》一书。
在此我还想感谢我的父母、兄弟和朋友们，他们对我日夜守在电脑前的疯狂给予了最大限度的容忍。如果没有他们的耐心、指导和爱，就不会有就不会有今天这本书。前言
无论是传统的企业型应用，还是当下的Web应用，作为一种数据库平台，PostgreSQL在为这些应用程序提供数据存储服务方面的可行性日趋成熟。不过，要想获取PostgreSQL的最佳性能，一直以来都并非易事。用户需遵循适宜的经验法则，需持续监控和维护以保障数据库系统健康运行，需以合理化建议定位和处理当前问题，需对数据库相关的附件工具有所涉猎，以便遇到核心数据库无法解决的问题时，可以为其进行功能扩展。本书内容概述
第1章介绍了PostgreSQL最近几个版本的性能改进情况。通常，人们认为所有软件的新版本会问题百出，而且会比以前的版本运行得更慢，但PostgreSQL不存在这个问题。
第2章讨论了如何仔细挑选服务器硬件中的主要部件，包括处理器、内存以及磁盘等，在预算允许的情况下如何组建一个稳定可靠的数据库存储服务器。特别是在磁盘控制器和驱动器方面，如果误用了易失性回写缓存，很容易导致数据库损坏。
第3章讨论了不同数据库硬件性能方面的量化标准。比如在你的系统当中，内存读取到底有多快？磁盘的原始性能有多强？在添加更多的磁盘后，数据库性能是否能正常按比例提升？
第4章研究现行文件系统的可选方案，并就如何权衡硬盘中数据库的不同布局提出建议。同时也讨论了一些常见的有效文件系统的调优问题。
第5章深入研究了数据库在磁盘、内存中的存储机制，并解释了checkpoint进程是如何协调这两种存储机制以保证数据安全的。此外，该章还讨论了如何深入查看数据库所缓存的数据，以及在此基础上，确认当下存储在系统内存里的数据与你的预期数据是否一致。
第6章涵盖了postgresql.conf文件中的最重要的一些设置选项，介绍了这些选项的含义以及如何设置这些选项。此外，也指出了可能会引起问题的设置。
第7章首先阐释了PostgreSQL如何判定哪些行数据对哪些用户可见。这些可见性信息的存储方法需要一个名为VACUUM的清理进程来正常地重新使用剩余空间。此外，该章也涉及了一些常见问题以及针对这些问题的调节方式，也涵盖了一直运行的autovacuum。最后，该章介绍了数据库日志的数据量调节方式，以及如何使用查询日志分析器对结果进行分析，从而帮助用户找出查询瓶颈。
第8章研究如何使用PostgreSQL自带的pgbench测试程序来获取有用的基准评测结果。
第9章介绍索引在响应查询时是如何减少数据块的读取量的。这种方法可以彻底探索一些常见问题，比如为什么一个查询会使用顺序扫描而不是使用强大的索引扫描。
第10章是PostgreSQL optimizer（优化器）指南，根据一些查询例子的不同执行方式以及数据库参数的不同设置，来说明数据库的不同优化方式。
第11章介绍了数据库内部所收集的统计信息，以及哪些信息有助于查找问题。同时，也介绍了能够让你看到查询活动以及锁行为的一些视图。
第12章先介绍了如何使用操作系统所提供的基本监视工具以确定数据库的当前动作。然后，该章针对可按照时间对信息趋势进行图形化表示的软件给出了建议。
第13章对在同一时间内对数据库进行大量连接时所遇到的困难进行了说明。同时，建议使用两种软件包——连接池（以更好地对请求进行排序）和缓存（在不连接数据库的情况下响应用户请求）——来帮助解决这些问题。
第14章讲述了如何通过跨节点复制数据来减轻数据库的负载压力，典型的解决方式是，多个同步只读的从节点搭配一个可读写的主节点。
第15章探讨如何有效地将数据划分为子集，这样可以在数据库的一小部分上执行查询。所讨论的方法包括单节点数据库表分区和使用PL/Proxy及其相关工具集来构建跨多节点的共享数据库。
第16章探讨那些在PostgreSQL中看起来阻碍初学者使用的部分。重点是如何找到代码不工作的原因，以及有哪些现有工具可以帮助诊断问题。
第17章以统计记录数和外键处理作为例子，涵盖了所有批量导入部分。同时，该章还包括人们使用PostgreSQL时所遇到的常见问题。
第18章详细介绍了从PostgreSQL 8.1到9.6各个版本中与性能相关的功能变化情况。有时，避免常见问题并获得更好性能的最佳方式就是升级到不再存在问题的新版本。你需要为阅读本书准备什么
为了更好地利用本书，你至少需要一个能够连接服务器并执行查询的PostgreSQL客户端。理想情况下，你最好也是服务器管理员。从http://www.postgresql.org/download上可以下载支持各种主流操作系统的完整客户端与服务端PostgreSQL安装包。本书的所有例子都是通过命令行方式执行的，通常是运行psql程序。这样可以使它们适合大多数操作系统平台。这样可以直接进行许多操作，而不必使用PostgreSQL的图形界面（GUI）工具，比如pgAdmin III程序。
本书提供的一些脚本是用bash脚本语言编写的，如果你使用的是Windows操作系统，可以从http://www.cygwin.com/下载cygwin软件套件，cygwin可以在Windows系统中提供常见的UNIX工具，比如bash。本书读者
本书适用于那些使用或计划使用PostgreSQL的中高级数据库管理员和开发人员。系统管理员可以在安装、配置和监视数据库服务器方面受益。本书对开发人员在编写最佳查询并在其数据库设计中检测性能问题方面也会有所帮助。同时，本书也有利于PostgreSQL内部架构师使用基准评测工具监控性能。下载示例代码
你可以通过http://www.packtpub.com用你的账户下载本书的示例代码。如果你从其他地方购得此书，可以直接访问http://www.packtpub.com/support去注册，来获得相关文件的邮件。
你可以通过以下步骤下载代码文件：
1）使用你的e-mail地址和密码在Packt网站上登录或注册；
2）将鼠标指针悬停在顶部的“SUPPORT”选项卡上；
3）点击“Code Downloads&Errata”；
4）在搜索框中输入图书的名称；
5）选择你要下载代码文件的图书；
6）从下拉菜单中选择你的购书途径；
7）点击“Code Download”下载。
文件下载后，请确保使用以下最新版本的文件解压缩软件：
·WinRAR/7-Zip（Windows）
·Zipeg/iZip/UnRarX（Mac）
·7-Zip/PeaZip（Linux）
本书示例代码包同样可以从GitHub上下载，网址是：https://github.com/PacktPublishing/PostgreSQL-9.6-High-Performance。第1章PostgreSQL版本
PostgreSQL已是声名在外，它丰富的功能和非常稳定的版本更是为人称道。PostgreSQL默认的安全配置让注重安全的拥趸者赞赏有加，但其学习难度也备受指责。对于SQL规范的一致性和数据完整性的支持，PostgreSQL只允许以最严格的方式与数据库进行交互，那些已经习惯了相对宽松的桌面数据库软件的用户对此很不适应。所有的这些观点都有其道理。
PostgreSQL运行速度慢也是它出名的一个原因，但是新发布的PostgreSQL在性能方面已经有了显著提升。在许多数据库操作中，“正确的事”总是伴随着更多的时间花销。举个最简单的例子，假如你要往一个日期字段存储一个并不存在的日期，2009年2月29日，数据库最快的方式就是不管对错，把它作为一个抽象的日期直接存进去，这样确实可以，而且也很快。或者，数据库也可以检查这个日期是否合法，发现正常的日历上没有这一天，然后拒绝你的修改，但这样做就会导致数据库的处理速度稍微慢一些。PostgreSQL的设计者和目标用户是同一类人，他们不会为了让事情变得更快更容易就偷工减料。如果正确解决某个问题的唯一方式要花费一段时间，那对他们来说，这个方法就是唯一正确的选择。
当然，一旦有了正确的方法，你还可以回过头去优化它。在过去几年里，PostgreSQL就是以这样的方式来演进的。这样的日积月累，造就了今天PostgreSQL卓越的性能。PostgreSQL的某些功能设计得非常好，即使因为复杂性造成了额外开销，其性能也远胜于那些简单的实现。虽然这是相当新的一个现象，但这个现象也解释了为什么很多人认为PostgreSQL比它的竞争对手要慢。
本章将讨论以下主题：
·PostgreSQL历代版本的性能
·选择PostgreSQL还是其他数据库
·PostgreSQL工具
·PostgreSQL应用程序的扩展生命周期
·在实践中做PostgreSQL性能调优1.1 PostgreSQL历代版本的性能
2016年9月，PostgreSQL 9.6发布了。它包含了若干内部架构的改进和显著的性能提升，例如对顺序扫描、聚集函数和连接操作的并行处理。特别是改进了多CPU服务器的扩展性。完整的修改日志参见https://www.postgresql.org/docs/9.6/static/release-9-6.html。
新版本在数据库的向上扩展能力方面有了巨大的提升，可以应付非常巨大的负载。在现代硬件上的基准评测结果也确实表明了这个版本比早期的版本有了很多质的飞跃。下面是从8.3版到9.6版的详细基准评测结果，其中PostgreSQL工具pgbench用于对不同版本PostgreSQL进行基准评测。完整的文档请见https://www.postgresql.org/docs/current/static/pgbench.html。
该测试以每秒处理事务数（TPS）为单位，对只读事务和读/写事务的系统总体速度进行了衡量。这里是从8.3版到9.6版混合模式（读/写）事务处理速度的对比。
你可以很容易地得知各版本的性能情况，当客户端数量增加时，你会注意到TPS值也在随之增加，但是当客户端数量达到某个峰值时，TPS值同时也开始下降。这也就表明了这个版本的数据库在该特定硬件下所能处理的最大客户端数量。从峰值负载情况下的用户数提升方面，我们就可以看出新版本的数据库内部对访问共享资源部分做了很多优化工作，相对于8.4/8.3版，9.6版这部分的提升效果非常显著。只读基准评测结果（8.3~9.6版本）
尽管其他基准评测所覆盖的版本没有这么广，但其他测试的结果也确实证实了新版本所带来的性能提升。在2005年年底之前PostgreSQL 8.1发布的时候，所有之前关于PostgreSQL性能测试的结论就已经完全过时了。PostgreSQL 9.0在运行速度提升方面有了额外的巨大飞跃，但是性能不是我们选择9.0（或其后的版本）的唯一原因，还有很多其他原因使我们更倾向于使用9.0（或其后的版本）。
更多PostgreSQL基准评测详情，请参阅http://blog.pgaddict.com/posts/performance-since-postgresql-7-4-to-9-4-pgbench。1.1.1 选择要部署的版本
如上所述，如果你想让手上的旧版PostgreSQL运行得更快，首先要考虑的事情不是如何调整设置，而是看是否有可能把它升级为最新版本。倘若你要开始一个新项目，那你首先应该考虑使用当前最新的PostgreSQL 9.6版本。除了性能改进之外，新版本的其他一些改动有可能会影响你的应用程序编码，你最好提前确认，以免后期返工。
本书的最后一章有一个参考指南，里面包括了从8.4到9.6每个PostgreSQL主要版本中所增加的与性能相关的特性介绍。你可能会发现某个吸引你的特性只有在最新的版本中才有，这也会促使你选择新的版本。在本书中，我们对这些版本所带来的各种变化也进行了重点说明。1.1.2 升级到一个新的主版本
过去PostgreSQL主版本的升级要使用dump和reload（比如从9.1.x升级到9.2.x）。在较新一些的版本中，用户会使用pg_dump和pg_dumpall程序将整个数据库的内容写入到一个文件中。采用这种方式，如果在升级中需要做某些变更，那新版的dump工具就会尝试处理。当然，不是所有的升级变更都会自动发生。根据dump的不同格式，你可以直接运行生成的脚本来还原数据，或使用pg_restore程序来还原。对新版本PostgreSQL来说，pg_restore是一个更好的替代方案，而且还具有并行还原的能力。
如果你使用的系统很难同时运行多个PostgreSQL版本，例如RedHat的Linux RPM包，就很难同时安装新版和旧版PostgreSQL。确保你的系统能同时运行多个版本的PostgreSQL，作为你升级计划的一部分。
dump过程需要一些时间，而还原过程花费的时间更久。在此期间，你可能需要停止数据库服务，以保证没有其他的更改。对大型数据库来说，停机时间会很长，甚至让人无法接受。
有些关键系统需要0宕机时间、24/7运行，针对这种系统的PostgreSQL升级，现在已经有语句级复制的可行方式。Slony（http://slony.info/）是这方面最流行的工具，详细信息将在后续复制章节介绍。Slony的一个特性是，你无须在要复制的所有节点上都运行相同版本的PostgreSQL。你在一个新节点上运行新版PostgreSQL，等待复制完成，只要新节点与原节点数据匹配，就可以切换到新节点。
现在PostgreSQL提供了一种新的方式，不需借助于任何复制软件，这就是pg_upgrade（https://www.postgresql.org/docs/9.6/static/pgupgrade.html）。每次发行PostgreSQL的时候会包含这个工具，它可以实现升级数据库版本而无需dump和reload，这个过程称为就地升级（in-place upgrading）。不过就地升级有一些风险，需要仔细测试，许多情况下它可以帮你从PostgreSQL 8.3版本升级到最新版本。
PostgreSQL开发社区现在致力于允许用户对未来的版本进行就地升级。现在TB级甚至更大数据量的PostgreSQL的安装已经很多，只靠dump和reload进行升级已经不现实了。
小版本升级
类似于从9.4.3到9.4.4这样的小版本升级是不需要dump/reload或pg_upgrade等工具的。用户只要简单地停止服务，安装新版本，然后在现有数据库数据文件上运行新版本数据库程序即可。部分用户从来不愿意在已经运行的程序上进行这样的升级，担心数据库程序的改动会引发问题。这种事情在PostgreSQL上绝对不会发生。PostgreSQL的项目原则在http://www.postgresql.org/support/versioning上有清楚的描述：
升级多少总会有风险，但PostgreSQL的小版本升级仅修复经常遇到的安全性问题和数据损坏错误，以减小升级风险。社区认为不升级比升级的风险更高。
在PostgreSQL的小版本升级中，永远不会有破坏应用程序的不可预期的修改。漏洞、安全性和损坏性修复被控制在最小范围内，并且尽量不会引起外部行为的变化。即使存在无法避免的变化，PostgreSQL也会在其发行说明中详细解释，并说明原因和建议的解决方案。一些因为修改漏洞引入的不易觉察的错误，会在小版本更新中得到彻底解决。在PostgreSQL的邮件列表中经常会见到某些问题在小版本升级中被解决的报告，所以升级到最新版本才是解决这些问题的办法。1.2 选择PostgreSQL还是其他数据库
的确，在某些场景中其他数据库表现得更好。例如，在TPC-H测试套件中，PostgreSQL缺少针对一些复制查询优化的功能（具体内容详见第8章）。它在大规模数据仓库的应用中，比一些商业数据库要弱一些。如果你需要执行TPC-H中包含的那些最复杂的查询，那么Oracle、DB2、SQL Server在这方面的一些性能优势值得你掏腰包。也有一些从PostgreSQL衍生出来的数据库，增加了一些功能使得它们更适用于数据仓库和大型系统。例如，Greenplum、Aster Data和Netezza。
对一些Web应用来说，除非舍弃对数据完整性的维护，否则性能无法接受，而这是PostgreSQL所不允许的。选择一个相对不是很严谨的数据库，比如MySQL，甚至迷你的SQLite，反而更适合这些Web应用。与已经很成熟的数据仓库市场不同，这类应用的设计还在持续变化。在本书编写之时，基于键值对（key-value）的NoSQL数据库（包括CouchDB、MongoDB和Cassandra）越来越流行。如果你只是进行简单查询，对运行键/值存储的高级查询所需的运行时间不敏感时，那么这些NoSQL数据库是很容易超越传统数据库的。
但对那些处于两个极端中间的“正常”数据库应用来说，PostgreSQL 9.6的性能已经足够，在数据库成为系统瓶颈之前，硬件和程序架构才是性能的限制因素。另外，PostgreSQL的传统优势（比如优秀的复杂查询处理能力、高度可编程性）都会保持下去。1.3 PostgreSQL工具
如果用户习惯于使用数据库供应商提供的从服务器管理到应用程序开发的数据库本身的完整工具集，PostgreSQL可能会让你大失所望。与大多数成功的开源项目一样，PostgreSQL尽量将重点放在它所擅长的功能上。引用开发社区的话就是，PostgreSQL的核心就是主数据库服务，相关的工具只能作为数据库本身的一部分来开发。当提出新功能时，首选的方式就是能够以“核心外”的方式构建和分发。
这种方法使数据库核心尽可能保持持续性，允许这些外部项目发布自己的更新，而不需要与主数据库的发布计划进行同步。
成功的PostgreSQL部署应该意识到，若干工具（每一个都有它自己特殊的用途）和数据库核心服务器整合在一起，才能构建成一个完整的系统。1.3.1 PostgreSQL contrib
作为PostgreSQL核心的一部分，对于名为contrib的模块，你可能并不需要安装，它们保存在contrib目录内。这些可选的实用程序和标准安装包一块发布，但默认情况下可以不安装。contrib代码作为PostgreSQL核心的一部分进行维护和分发，但PostgreSQL服务的运行并不依赖它们。
从代码质量的角度来看，contrib模块没有遵守很高的标准。主服务器件的每个功能都会进行大量的回归测试，包括在大量的系统中寻找错误。可选的contrib模块没有达到相同级别的测试覆盖水平。但代码本身是由同一开发团队进行代码维护，其中一些模块非常受欢迎，而且经过用户的良好测试。
请浏览https://www.postgresql.org/docs/current/static/contrib.html查看所有可用的contrib模块列表。
找到系统中的contrib模块
检查你是否安装了contrib模块的一个好方法是查看pgbench程序是否可用。pgbench是安装了完整程序的少数contrib组件之一，而不仅仅只是你可以使用的一个脚本。以下是在UNIX系统中检查pgbench的示例：
在大多数Linux系统中，如果用户使用的是RPM或DEB打包版本的PostgreSQL，则可选的postgresql-contrib软件包中包含所有contrib模块及其关联的安装程序脚本。如果尚未安装，你可能需要使用yum、apt-get或类似的机制添加此软件包。在Solaris系统上，这个软件包名为SUNWpostgr-contrib。
如果你不确定系统中PostgreSQL contrib模块的安装位置，可以使用文件系统工具进行搜索。在许多类UNIX系统上，locate命令和find命令都能很好地达到这个目的。Windows上可使用“开始”菜单中的文件搜索工具。你可以以文件pg_buffercache.sql为例进行查找，该文件将在第5章中用到，用于内存分配。以下是你可以在一些PostgreSQL支持的平台上找到该文件的地方：
·在RHEL和CentOS Linux系统中，该文件的安装位置为：
/usr/share/pgsql/contrib/pg_buffercache.sql
·在Debian或Ubuntu Linux系统中，该文件的安装位置为：
/usr/share/postgresql/version/contrib/pg_buffercache.sql
·在Solaris系统中的安装位置为：
/usr/share/pgsql/contrib/pg_buffercache.sql
·在Windows系统中，默认会安装contrib模块，安装位置为：
C：\Program Files\PostgreSQL\version\share\contrib\pg_buffercache.sql
从源代码安装contrib模块
如果你的服务器上已经安装了合适的依赖环境，那么在一些平台上通过源代码来编译你自己的PostgreSQL会是一件简单的事。详见文档：
https://www.postgresql.org/docs/current/static/install-procedure.html
在编译完主服务器的代码后，你还需要自己编译pg_buffercache等contrib模块。下面是一个如何操作的相关例子，假定你的PostgreSQL位置是在/usr/local/postgresql，并且源代码存放在该目录下的source目录（这种目录结构并非是典型或推荐使用的目录结构）。例子如下：
也可以通过在contrib目录下运行make和make install来编译和安装所有的contrib模块。需要注意的是，其中一些contrib模块有更多的源代码编译要求。比如uuid-ossp模块的编译就具有一定的挑战性。
contrib模块的使用
虽然一些contrib程序（如pgbench）可以直接执行，但大多数都需要安装到数据库中，从而增加额外的功能。
例如，要将pg_buffercache模块安装到名为abc的数据库中，可以使用如下命令（假定文件在RedHat系统的位置）：
作为可选项，用户也可以使用pgAdmin III图形管理程序（GUI）来代替命令行完成contrib模块的安装（pgAdmin III与PostgreSQL的Windows安装程序是捆绑在一起的）：
1）导航到要安装contrib模块的数据库。
2）单击工具栏中的SQL图标以显示命令编辑器。
3）选择File/Open。选择C：\Program Files\PostgreSQL\version/share/contrib/pg_buffercache.sql，并打开该文件。
4）选择绿色箭头或Query/Execute去执行。
无论在什么类型的系统上，你都可以通过运行下面这个很短的查询语句来快速测试模块是否安装好了。
如果有任何结果返回，表示模块已安装。请注意，pg_buffercache只能由数据库超级用户安装和使用。
使用PostgreSQL扩展
PostgreSQL引入了另一种方式来安装contrib模块，称为扩展（extension）。此方法适用于所有使用扩展规范构建的contrib模块，包括：
·扩展SQL文件（extension_name.sql）
·扩展控制文件（extension_name.control）
·扩展库文件（extension_name.so）
我们来看下面的命令：
·CREATE EXTENSION extension_name：此命令将安装一个名为dummy的新扩展，因此不需要像在安装pg_buffercache时手动执行一个sql文件。
·ALTER EXTENSION extension name：此命令将更改扩展名，大多用于升级扩展。
·DROP EXTENIONS extension_name：在清理操作完成后，此命令用于删除一个扩展。1.3.2 pgFoundry
很多PostgreSQL相关的项目的官方站点是pgfoundry，网址是http://pgfoundry.org/。
pgFoundry仅托管PostgreSQL相关的软件，除了文件分发之外，它还提供邮件列表和错误跟踪等资源。许多最流行的PostgreSQL附加程序都在那里托管，其中包括：
·允许通过.Net和OLE访问PostgreSQL的Windows软件
·连接池软件，如pgpool和pgBouncer
·数据库管理工具，如pgFouine、SkyTools和pgtune
虽然有时是由PostgreSQL核心组的同一批人维护pgFoundry，但pgFoundry的代码质量差异还是很大。发现比较好的项目的方法便是查看该项目的发布周期和近期的版本发布。1.3.3 其他PostgreSQL相关软件
除了PostgreSQL核心自带的程序、contrib模块和pgFoundry上提供的软件之外，还可以从互联网上获取许多其他程序，以使PostgreSQL更易用和更强大。实际上有这么多可根据要求选择的包，这本身就有压倒性的优势了。
本书会突出介绍一些优秀的程序，以提供一个可以优先考虑的可选列表。先运行一个基本系统，然后根据需要添加其他组件，这种方式也是构建大型开源项目的标准方式。
对于安装任何软件都需要经过审批到质量保证（QA）环节的企业来说，对此可能比较难以适应。为了提高此类用户环境中的PostgreSQL安装的成功率，在早期就引入这一概念是很重要的——在后期需要的时候再将附加程序添加到较小的数据库核心中去，而不是在一开始就将所有会涉及的组件全部安装上去。1.4 PostgreSQL应用程序的扩展生命周期
虽然每个应用程序都有其独特的发展方面，但随着使用PostgreSQL数据库的应用程序增多，你会发现许多常见的技术也变得必不可少。本书的每个章节都着重介绍了这一过程中的一个常见方面。搭建数据库服务器通常有如下步骤：
·选择运行服务器的硬件。理想情况下，你应该测试该硬件，以确保其性能能达到预期。
·设置数据库磁盘的各个部分布局：RAID级别、文件系统和磁盘上可能的表/索引布局。
·优化服务器配置。
·监控服务器性能以及查询执行情况。
·改进查询效率，或者添加索引以提高查询速度。
·在难以通过调整服务器来增加其工作负荷的情况下，通过引入连接池和缓存来减少服务器调整方面的担忧。
·将数据复制到多个服务器，并在这些服务器上分布式读取数据。
·将大的表分成多个部分。最终那些确实很大的表可能需要拆分，以便能够同时写入多个服务器中。
这一过程并非一成不变，用户会反复进行服务器的参数优化。用户也可能会决定先购买新的硬件设备，而不是为了要支持数据库的复制或者分区操作，开始重新设计那些应用程序。部分设计在一开始可能就已经将缓存集成到了设计中。重要的是，用户要意识到有很多可用选项，并收集限制系统性能的足够数据，从而确定何种可能的更改最有利。1.5 在实践中做性能优化
就像其他领域一样，提高数据库性能也有专门的术语。以下是本书中将使用的一些术语或短语：
·瓶颈或限制因素：这两个术语用于指当前阻碍性能的限制。
·基准评测：这是指运行一个测试来确定某个特定操作能达到的性能，通常是为了发现程序或系统的瓶颈。
·性能分析（profiling）：这是指监控程序在运行复杂操作（如性能测试）时，哪些部分占用了最多的资源。这通常用于指明瓶颈的位置，以及经过更改后，该瓶颈是否按照预期被消除。分析一个数据库应用程序通常从监控工具（如vmstat和iostat）开始。代码级的热门分析工具包括gprof、oprofile和dtrace。
性能调优工作的一个有意思的定律是，一般来说，用户无法确定应用程序将遇到的下一个瓶颈是什么，直到你移除当前的瓶颈。当系统表现得不如人们期望的那样快时，用户经常会去猜目前的瓶颈是什么，或下一个瓶颈又会是什么。这通常都是在浪费时间。用户最好去
试读结束[说明：试读内容隐藏了图片]