雖然 PostgreSQL 中的索引不需要維護或調整，但檢查實際查詢工作負載使用了哪些索引仍然非常重要。 檢查單個查詢的索引使用情況是使用 EXPLAIN 命令完成的；其在此目的上的應用在 第 14.1 節中進行了說明。 也可以收集關於執行中伺服器中索引使用情況的整體統計訊息，如 第 27.2 節中所述。
很難制定一個通用的過程來確定要建立哪些索引。 在前面的章節中的範例中，已經展示了許多典型的案例。 通常需要大量的實驗。 本節的其餘部分提供了一些技巧。
始終先執行 ANALYZE。 此命令收集有關表中值分佈的統計訊息。 規劃器需要此訊息來估算查詢傳回的列數，以便為每個可能的查詢計畫分配實際成本。 在沒有任何真實統計訊息的情況下，會假設一些預設值，這些值幾乎肯定是不準確的。 因此，在沒有執行 ANALYZE 的情況下檢查應用程式的索引使用情況是徒勞的。 有關更多訊息，請參閱 第 24.1.3 節和 第 24.1.6 節。
使用真實資料進行實驗。 使用測試資料來設定索引將告訴您測試資料需要哪些索引，僅此而已。
使用非常小的測試資料集尤其致命。 雖然從 100000 列中選取 1000 列可能是索引的候選對象，但從 100 列中選取 1 列幾乎不可能，因為 100 列可能適合單個磁碟頁面，並且沒有任何計畫可以勝過循序擷取 1 個磁碟頁面。
建立測試資料時也要小心，當應用程式尚未投入生產時，這通常是不可避免的。 非常相似、完全隨機或按排序順序插入的值會使統計訊息偏離真實資料的分佈。
當未使用索引時，強制使用它們對於測試很有用。 有一些執行階段參數可以關閉各種計畫類型（請參閱 第 19.7.1 節）。 例如，關閉循序掃描 (enable_seqscan) 和巢狀迴圈聯結 (enable_nestloop)，它們是最基本的計畫，將強制系統使用不同的計畫。 如果系統仍然選擇循序掃描或巢狀迴圈聯結，則可能存在更根本的原因導致未使用索引； 例如，查詢條件與索引不符。 （在前面的章節中說明了哪種類型的查詢可以使用哪種類型的索引。）
如果強制使用索引確實使用了索引，那麼有兩種可能性：系統是正確的，並且使用索引確實不合適，或者查詢計畫的成本估算並未反映現實。 因此，您應該在有和沒有索引的情況下計時您的查詢。 EXPLAIN ANALYZE 命令在這裡很有用。
如果結果證明成本估算有誤，同樣地，有兩種可能性。總成本是根據每個計畫節點的每列成本乘以該計畫節點的選擇性估算值計算得出的。計畫節點的估計成本可以透過執行階段參數進行調整（詳見第 19.7.2 節）。不準確的選擇性估算歸因於統計資料不足。 可以透過調整統計資料收集參數來改善此情況（請參閱ALTER TABLE）。
如果您未能成功調整成本使其更為適當，那麼您可能必須採取強制使用索引的手段。您可能還需要聯繫 PostgreSQL 開發人員來檢查此問題。
如果您在文件中發現任何不正確、與您使用特定功能的經驗不符或需要進一步澄清的內容，請使用此表單來報告文件問題。