尽管在 PostgreSQL 里的索引并不需要维护和调节， 但是检查一下哪些索引是在实际查询工作中得到使用的仍然是非常重要的． 检查索引的使用是通过 EXPLAIN 命令进行的； 为此目的做的应用在 Section 13.1 里演示． 我们也可以在一个运行的服务器上收集有关索引使用的全部可能性， 就想在 Section 23.2 里描述的那样。
归纳一个判断需要设置哪些索引的通用过程是很难的． 在前面的章节中已经列出了许多典型的例子． 在大多数情况下我们都需要许多试验．本节的剩余部分就是给出一些这方面的窍门．
总是先运行 ANALYZE． 这条命令收集关于表中数值分布的统计．猜测一个查询返回的行数需要这个信息， 而规划器需要这个行数以便给每个可能的查询规划赋予真实开销值． 如果缺乏任何真实的统计信息，那么就会假设一些缺省数值， 那肯定是不准确的．因此，如果还没有运行 ANALYZE 就检查一个应用的索引使用状况，那实际上就是一次失败的检查．
使用真实的数据做实验．用测试数据设置索引将告诉你在测试数据中需要什么索引，而不是在所有数据中．
最要命的是用按比例缩小的数据集．如果从 100000 行中选 1000 行是使用索引的好时机， 那么从 100 行中选 1 行很难说也需要索引， 因为 100 行很可能是装在一个磁盘页里面的， 因此没有任何查询规划能比通过顺序访问抓取一个磁盘页面更有效．
做测试数据的时候也要小心 -- 如果应用还不能在生产环境中使用， 那么这也是不可避免的．那些非常相似的数据，完全随机的数据， 或者按照排序顺序插入的数据会令统计信息偏离实际数据应该具有的特征．
如果索引没有得到使用，那么在测试中强制它的使用也许有些价值． 有一些运行时参数可以关闭各种各样的查询规划（在 Section 16.4 中描述）． 比如，关闭顺序扫描（enable_seqscan）和嵌套循环连接（enable_nestloop）将强迫系统使用不同的规划。 （这些规划是最基本的规划。）如果系统仍然选择顺序扫描或者嵌套循环联接， 那么在为何索引没有得到使用的问题中可能有更基本的问题， 比如，查询条件和索引不匹配等．（我们在前面的章节中介绍了什么样的查询可以使用什么样的索引．）
如果强制索引用法的确使用了索引，那么就有两种可能∶ 要么是系统选择是正确的∶使用索引实际上并不合适， 要么是查询计划的开销计算并不反映现实情况． 这样你就应该对使用和不使用索引的查询进行计时．这个时候 EXPLAIN ANALYZE 命令就很有用了．
如果实际情况说明开销计算是错误的，那么仍然有两种可能． 总开销是从每行的每个规划节点乘以每个规划节点的选择性估计的开销计算出来的。 规划节点的开销可以用一些运行时参数进行调节（在 Section 16.4 中描述）。 不准确的选择性估计是因为统计信息不够充分。 我们可以通过调节统计收集参数（参阅 ALTER TABLE）提高选择性估计的精确度。
如果你没能通过将开销调整得更准确实现索引的使用，那么你可能不得不 求助于明确地强制索引使用．而且也许与 PostgreSQL 开发人员联系并且讨论你的情况也是值得考虑的．