PostgreSQLはインデックスのメンテナンスやチューニングは必要ありませんが、どのインデックスが実際の問い合わせで使われているかを確認することは重要です。インデックスの使用状況はEXPLAINコマンドで確認でき、このコマンドの目的はSection 11.1に書かれています。
どのインデックスを作成すべきなのか、ということの一般的な手順を示すことは難しいことです。したがって、これまでの節では一般的なケースを多く記しました。多くの場合、十分な実験が必要です。その実験のための秘訣をこれから書き記します。
まず、必ず最初にANALYZEコマンドを実行して下さい。このコマンドはテーブル内のデータ分布の統計情報を収集します。この情報は、問い合わせを実行したらいくつの行が返るかを推測する際に必要となります。また、プランナが利用できる各問い合わせ計画に実際のコストを割り当てる際に、この推測値が必要とされます。実統計情報が少しでも欠如している場合、全くといってよい程不正確な何らかのデフォルト値が推定されます。したがって、ANALYZEコマンドを実行せずにアプリケーションのインデックス使用状況を調査することは、あまり意味がないことになります。
実験では、実際に使用するデータを使って下さい。テストデータのインデックスを作成した場合は、テストデータ用のインデックスとなるので、テストを行なう意味があまりありません。
データ数の割合を縮小することも意味がありません。100000件のデータの中から1000件のデータを検出する場合はインデックスが使用される可能性がありますが、100件のデータの中から1件のデータを検出する場合は、100件のデータというのは1つのディスクページに収まりますので、インデックスを使用しないで、100件を順にスキャンする可能性が高いです。
また、アプリケーションが実動するまでの間、実データはありませんのでテストデータを作成する必要がありますが、その際にも注意が必要です。よく似ている値や、完全にランダムな値、あるいは順序にしたがってデータが登録されている場合は、統計情報と実際のデータの分布とでかけ離れたものとなってしまいます。
インデックスが使用されていない場合、実験的に、インデックスを強制的に使用するようにできます。実行時パラメータを使用することによってどの実行プランを有効にするかの指定が可能です(詳細は管理者ガイドを参照して下さい)。例えば、一般的な実行プランである逐次スキャン(enable_seqscan)と入れ子ループ結合(enable_nestloop)を使用しないように設定した場合、データベースシステムは他の実行プランを使用するように強制します。もしそのような設定を行なってもデータベースがインデックスを使用しないで、逐次スキャンや入れ子ループ結合を選択する場合は、もっと根本的な問題があり得ます。このような例として、問い合わせの条件がインデックスに該当しない場合などが考えられます。(どのような問い合わせが、どのようなインデックスを使用するかは前の節で説明済みです。)
強制的にインデックスを使うように設定し、実際にインデックスを使用する場合は、次の2つのことが言えます:システムは正常に稼働しているが、インデックスの使用は適切ではない、あるいは問い合わせプランの実行時間推測値が不適切であるということです。したがって、インデックスを使った問い合わせの実行時間と、使わない場合の実行時間を計測する必要があります。この場合、EXPLAIN ANALYZEが便利です。
もし実行時間の推測値が間違っている場合、その理由として2つのことが考えられます。実行時間の合計とはプランノードの行単位のコストにプランノードの選択性推測値を掛けた値です。プランノードの実行時間は実行時パラメータによって設定することができます(詳細は管理者ガイドを参照して下さい)。不適切な選択性推測値は、不十分な統計情報に基づくものです。統計情報収集用のパラメータを調節することによって、これを回避することができます。(ALTER TABLEを参照して下さい。)
適切な実行時間に調節できない場合は、明示的にインデックスの使用を強制する必要があります。あるいは、PostgreSQL開発者に状況調査の依頼をしてみて下さい。