2.统计信息收集和管理
正确的统计信息对查询优化器得出较好的执行计划有十分重要的影响，在大量插入或更新数据以后，包括对表进行rebuild后，需要重新收集统计信息。前面已经使用了VACUUM ANALYZE命令。
这个命令其实是VACUUM命令的一种形式，表示垃圾收集以分析一个数据库，VACUUM命令语法如下：
VACUUM [ FULL | FREEZE ] [ VERBOSE ] [ table ]VACUUM [ FULL | FREEZE ] [ VERBOSE ] ANALYZE [ table [ (column [, ...] ) ] ]VACUUM 回收已删除记录占据的存储空间。在一般的 PostgreSQL 操作里， 那些已经 DELETE 的记录或者被 UPDATE 过后过时的记录是没有从它们所属的表中物理删除的; 在完成 VACUUM 之前它们仍然存在。因此我们有必须周期地运行 VACUUM， 特别是在常更新的表上。
如果没有参数，VACUUM 处理当前数据库里每个表， 如果有参数，VACUUM 只处理那个表。
VACUUM ANALYZE 先执行一个 VACUUM 然后是给每个选定的表执行一个 ANALYZE。 对于日常维护脚本而言，这是一个很方便的组合。
简单的 VACUUM (没有FULL)只是简单地回收空间并且令其可以再次使用。这种形式的命令可以和对表的普通读写并行操作， 因为没有请求排他锁。VACUUM FULL 执行更广泛的处理，包括跨块移动记录，以便把表压缩到最少的磁盘块数目里。 这种形式要慢许多并且在处理的时候需要在表上施加一个排它锁。
下面再介绍另一个ANALYZE命令，可以收集指定表的统计信息。语法如下：
ANALYZE [ VERBOSE ] [ table [ (column [, ...] ) ] ]ANALYZE 收集有关 PostgreSQL 表的内容的统计，然后把结果保存在系统表 pg_statistic 里。随后，查询优化器就可以使用这些统计帮助判断查询的最有效的规划。
如果没有参数，ANALYZE 检查在当前数据库里的所有表。 如果有参数，ANALYZE 只检查那个表。还可以给出一列字段名字，这个时候只收集那些字段的统计信息。
比如，对part表收集统计信息。
pgdb=# analyze part;ANALYZETime: 667.500 ms周期性地运行 ANALYZE，或者在对表的大部分内容做了更改之后马上运行它是个好习惯，准确的统计信息将帮助优化器选择最合适的查询规划，并因此而改善查询处理的速度。 一种比较经常采用的策略是每天在低负荷的时候运行一次 VACUUM 和 ANALYZE。
和 VACUUM FULL 不同的是， ANALYZE 只需要在目标表上有一个读取锁， 因此它可以和表上的其它活动并行地运行。
收集的统计信息通常包括一个每字段最常用数值的列表以及一个包线图，显示每个字段里数据的近似分布。
对于大表，ANALYZE 采集表内容的一个随机的抽样做统计，而不是检查每一行。这样就保证了即使是在很大的表上，我们也只需要很少的一些时间就可以完成分析。 不过，要注意的是统计只是近似的结果，在很小的概率的情况下，这个不确定的行为会导致查询优化器在不同 ANALYZE 之间选择不同的查询规划。为了避免这个问题，可以提高 ANALYZE 收集的统计数量。
PostgreSQL还有很多功能，如分析函数、递归with查询，已经超出了tpc-h测试的范围，留给读者测试。
四、小结
经过这次测试，我们对PostgreSQL数据库已经有了初步的印象，安装比较简便，安装包也体积较小，但功能还是很强大，对SQL标准的支持较好，总体性能也比较好，比如数据文件导入和查询。其次，对于TPC-H这种分析型查询，添加主外键约束后能产生较好的执行计划。优化器产生执行计划的速度也比较快。提供了跨平台的安装包，便于各类用户使用。第3方厂商提供了一个图形化的管理工具pgadmin，某些平台的安装包也集成了该工具，便于PostgreSQL数据库管理和开发。
存在的问题，首先，不知是否是免费开源数据库的通病，不支持单个查询并行执行，要充分利用硬件资源的只能依赖多个连接并发处理。其次，虽然号称是非常先进的开源数据库，仍缺少数据压缩功能，分区功能也比较薄弱。再有，数据库的一些概念和功能比较独特，比如集群、用户组和继承，以及一些特殊的操作符，需要花一定时间学习，如果用到了，会导致应用可移植性略差。最后，文档和支持，PostgreSQL的文档较少，相关的书籍也较少，性能优化的难度较高。
总的来说，PostgreSQL是一个功能强大，性能优良，运行稳定的免费数据库，适合于各种OLTP系统，但对于批处理的分析类系统，在硬件资源利用方面还有待提高。
