虽然 PostgreSQL 中的索引不需要维护或调优，但检查实际查询工作负载实际使用了哪些索引仍然很重要。使用 EXPLAIN 命令来检查单个查询的索引使用情况；本节在 第 14.1 节 中说明了其在此方面的应用。还可以收集有关正在运行的服务器中索引使用情况的总体统计信息，如 第 27.2 节 所述。
很难制定一个确定要创建哪些索引的通用过程。前面的章节中的示例已显示了许多典型情况。通常需要进行大量实验。本节的其余部分提供了一些技巧
务必先运行 ANALYZE。此命令收集有关表中值分布的统计信息。此信息对于估算查询返回的行数至关重要，而规划器需要这些信息来为每个可能的查询计划分配真实的成本。如果没有实际的统计信息，将假定一些默认值，这些值几乎可以肯定是不准确的。因此，在未运行 ANALYZE 的情况下检查应用程序的索引使用情况是徒劳的。有关更多信息，请参阅 第 24.1.3 节 和 第 24.1.6 节。
使用真实数据进行实验。使用测试数据来设置索引将告诉您测试数据需要哪些索引，但仅此而已。
使用非常小的测试数据集尤其致命。虽然从 100,000 行中选择 1,000 行可能是索引的候选，但从 100 行中选择 1 行几乎不会，因为这 100 行可能适合单个磁盘页面，并且没有计划可以优于顺序读取 1 个磁盘页面。
在创建测试数据时也要小心，当应用程序尚未投入生产时，这通常是不可避免的。非常相似、完全随机或按排序顺序插入的值将使统计信息偏离真实数据将具有的分布。
当索引未使用时，为了测试强制使用它们可能会很有用。有一些运行时参数可以关闭各种计划类型（请参阅 第 19.7.1 节）。例如，关闭顺序扫描（enable_seqscan）和嵌套循环连接（enable_nestloop），它们是最基本的计划，将强制系统使用不同的计划。如果系统仍然选择顺序扫描或嵌套循环连接，那么索引未使用的原因可能更根本；例如，查询条件不匹配索引。（前面几节解释了哪种查询可以使用哪种索引。）
如果强制使用索引确实使用了索引，那么有两种可能性：要么系统是正确的，使用索引确实不合适，要么查询计划的成本估算没有反映实际情况。因此，您应该对查询进行计时，分别在有和没有索引的情况下进行。 EXPLAIN ANALYZE 命令在这里可能很有用。
如果事实证明成本估算错误，那么同样有两种可能性。总成本是从每个计划节点的每行成本乘以计划节点的选择性估算值计算出来的。计划节点的估算成本可以通过运行时参数进行调整（请参阅 第 19.7.2 节）。选择性估算不准确是由于统计信息不足造成的。通过调整收集统计信息的参数（请参阅 ALTER TABLE）可能可以改善这种情况。
如果您未能将成本调整得更合适，那么您可能不得不诉诸于显式强制使用索引。您还可以联系 PostgreSQL 开发人员来审查此问题。