PostgreSQL読み取り専用テーブルを最適化する

フィルタリングに使用される列または参加（または、程度は低いですが、並べ替え ）インデックス作成に関心があります。選択したばかりの列はほとんど関係ありません！次のクエリでは、 aのインデックスのみを使用しますおよびe 役に立つかもしれません：

SELECT a,b,c,d
FROM   tbl_a
WHERE  a = $some_value
AND    e < $other_value;

ここで、 f そしておそらくc 候補者でもあります：

SELECT a,b,c,d
FROM   tbl_a
JOIN   tbl_b USING (f)
WHERE  a = $some_value
AND    e < $other_value
ORDER  BY c;

インデックスを作成したら、EXPLAIN ANALYZE 。また、インデックスがある場合とない場合の実行時間を比較します。インデックスの削除と再作成はすばやく簡単に行えます。実験のパラメーターもあります。 EXPLAIN ANALYZEを使用。違いは驚異的または存在しない可能性があります。
テーブルは読み取り専用であるため、インデックスのメンテナンスは安価です。単なるディスク容量の問題です。

自分が何をしているのかを本当に知りたい場合は、ドキュメントを読むことから始めてください> 。

どのクエリが予想されるかわからない場合...

典型的なユースケースを見つけるのに十分なクエリをログに記録してみてください。パラメータ log_statement = allを使用してクエリをログに記録しますそのために。または、 log_min_duration_statementを使用して遅いクエリをログに記録します。
インデックスを作成しますこれは便利な場合があり、しばらくしてから統計をチェックして、実際に何が使用されているかを確認してください。 PostgreSQLには、統計の監視のためのインフラストラクチャ全体が用意されています。。統計（および他の多くのタスク）を調査する便利な方法の1つは、pgAdmin です。ここで、テーブル/関数/インデックスを選択し、オブジェクトブラウザ（メインウィンドウ）の[統計]タブですべてのデータを取得できます。
上記の手順に従って、使用中のインデックスが実際に処理を高速化するかどうかを確認します。
クエリプランナーが1つ以上のインデックスを使用することを選択したが、影響がないか悪影響がない場合は、セットアップに問題がある可能性があり、パフォーマンス最適化の基本：バキューム、分析、コストパラメータ、メモリ使用量、...