PostgreSQL では、インデックスのメンテナンスやチューニングは必要ありませんが、どのインデックスが実際の問い合わせで使われているかを確認することは、やはり重要です。 インデックスの使用状況は、EXPLAIN コマンドで検証できます。この目的のための用例は、Section 10.1 に説明されています。
どのインデックスを設定すべきかを判断するための一般的な手順を定めることは困難です。 これまでの節では、例として典型的なケースをいくつか記述してきました。 多くの場合、十分な検証が必要です。 この節の残りで、検証のためのヒントをいくつか説明しておきます。
まず最初に、必ず ANALYZE コマンドを実行して下さい。 このコマンドにより、テーブル内の値の分布に関する統計情報を収集します。 この情報は、問い合わせにより返される行数を推測する際に必要となります。推測された行数は、利用できる各問い合わせ計画に実際のコストを割り当てるために、プランナで必要となります。 実際の統計情報が少しでも欠如している場合、何らかのデフォルト値が出力されます。このデフォルト値は、ほぼ間違いなく不正確です。 したがって、ANALYZE コマンドを実行せずに、アプリケーションのインデックス使用状況を検証しても、あまり意味がありません。
検証には、実際に使用するデータを使って下さい。 テストデータを使ってインデックスを作成した場合、テストデータに必要なインデックスはわかりますが、実際に必要なインデックスではないため、あまり意味がありません。
比率を変えずにデータ数を縮小することも、結果に特に致命的な影響を与えます。 100,000行から 1,000 行を選択する場合は、インデックスが使用される可能性がありますが、100 行から 1 行を選択する場合はインデックスはまず使用されません。なぜなら、100 行はおそらく 1 つのディスクページに収まるため、インデックスを使用するよりもページを逐次読み取った方が速いからです。
また、アプリケーションがまだ実動していない場合、テストデータを作成しなければならないことがよくありますが、その際にも注意が必要です。 非常に類似した値や、完全にランダムな値、またはソートされた順序で値が挿入されている場合は、その統計情報は、実際のデータの分布とかけ離れたものになってしまいます。
インデックスが使用されていない場合、テストのため、インデックスを強制的に使用するようにすると便利です。 実行時パラメータを使用することにより、どの計画を無効にするかを指定することができます (PostgreSQL 7.3 管理者用ガイドを参照して下さい)。 たとえば、最も基本的な計画であるシーケンシャルスキャン (enable_seqscan) および入れ子状ループ結合 (enable_nestloop) を使用しないように設定すると、システムは別の計画を使用するように強制されます。 そのような設定を行なっても、データベースがインデックスを使用せずにシーケンシャルスキャンや入れ子状ループ結合を選択する場合は、インデックスを使用しない理由としておそらくもっと根本的な問題があるということになります。たとえば、問い合わせの条件がインデックスに一致しない、などが考えられます。 (どのような問い合わせで、どのようなインデックスを使用できるかは、前の節で説明済みです。)
強制的にインデックスを使うように設定し、インデックスを使用している場合は、次の 2 つの状況が考えられます。 システムは正常に稼働しているが、インデックスの使用が実際には適切ではないという状況か、あるいは、問い合わせ計画のコスト見積もりが実情を反映していない状況です。 したがって、インデックスを使った問い合わせの実行時間と、使わない場合の実行時間を計測する必要があります。 この場合、EXPLAIN ANALYZE コマンドが便利です。
コスト見積もりが間違っていると判明した場合、やはり、2 つの状況が考えられます。 総コストは、各計画ノードの行単位のコストに、計画ノードの選択度見積もりを掛けることで算出されます。 計画ノードのコストは、実行時パラメータによって設定することができます (PostgreSQL 7.3 管理者用ガイドを参照して下さい)。 選択度コストが不正確であるのは、統計情報が不十分であるのが原因です。 統計情報収集用のパラメータを調節することによって、この状況を回避することができます (ALTER TABLE を参照して下さい)。
コストを適切に調節できない場合は、明示的にインデックスを使用する必要が考えられます。 あるいは、PostgreSQL 開発者に問題の調査を依頼することもできます。