Table of Contents
10.1. 使用 EXPLAIN
10.2. 规划器使用的统计信息
10.3. 用明确的 JOIN （连接）控制规划器
10.4. 向数据库中添加记录
10.4.1. 关闭自动提交
10.4.2. 使用 COPY FROM
10.4.3. 删除索引
10.4.4. 事后运行 ANALYZE
查询的性能可能受多种因素影响． 其中一些因素可以由用户操纵，而其他的则属于下层系统设计的基本问题了． 本章我们提供一些有关理解和调节 PostgreSQL 性能的线索．
10.1. 使用 EXPLAIN
PostgreSQL 为给它的每个 查询产生一个查询规划． 为匹配查询结构和数据属性选择正确的规划对性能绝对有关键性的影响． 你可以使用 EXPLAIN 命令察看系统为每个查询生成的 查询规划是什么．阅读查询规划是一门值得写一个相当长的教程的学问， 而我这份文档可不是这样的教程，但是这里有一些基本的信息．
目前被 EXPLAN 引用的数字是：
*
预计的启动开销（在输出扫描开始之前消耗的时间， 也就是，在一个排序节点里做排续的时间）．
*
预计的总开销（如果所有的行都被检索的话， 不过很可能不是这样 --- 比如 LIMIT 将在总开销的一小部分就停止）．
*
预计的这个规划节点输出的行数． （同样，只执行到完成为止）．
*
预计的这个规划节点的行的平均宽度（以字节计算）．
开销是以磁盘页面的存取为单位计算的． （预计的 CPU 处理用一些非常随意的捏造的权值被转换成磁盘页面单位。 如果你想试验这些东西，请参阅在 PostgreSQL 7.3 管理员手册 里的运行时参数列表．）
有一点很重要：那就是一个上层节点的开销包括它的所有子节点的开销。 还有一点也很重要：就是这个开销只反映规划器/优化器关心的东西。 尤其是开销没有把结果记录传递给前端的时间考虑进去 --- 这个时间可能在真正的总时间里面占据相当重要的分量， 但是被规划器忽略了，因为它无法通过修改规划来改变之。 （我们相信，每个正确的规划都将输出同样的记录集。）
输出的行数有一些小处理，因为它不是 查询处理/扫描过的行数 --- 通常会少一些， 反映对应用于此节点上的任意WHERE子句约束的选择性估计． 通常而言，顶层的行预计会接近于查询实际返回，更新，或删除的行数
下面是几个例子（用的是经过VACUUM ANALYZE后的回归测试数据库以及 7.3 的开发代码）：
regression=# EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
这个例子就象例子本身一样直接了当。如果你做一个
SELECT * FROM pg_class WHERE relname = 'tenk1';
