Postgres-インデックスによる挿入パフォーマンス
Postgres 9.2.10 DBに約20列のテーブルがあります。一部のSELECTクエリのパフォーマンスを向上させるために、データ型timestampの1つの列にインデックスを追加する予定です。インデックスも挿入のパフォーマンスを低下させる可能性があるため、次のパフォーマンステストを行いました。
テーブルに500万レコードを挿入しました。それが最大です。生産で予想されるレコード数。次に、タイムスタンプ列にインデックスがある場合とない場合で10000レコードを挿入する時間を測定しました。これは、1日あたりに予想される最大挿入数であり、ピーク時の1秒あたりの挿入数は5以下です。
ここに結果：
- インデックスあり-84441 ms
- インデックスなし-78 000 ms
少なくともこのテストでは、インデックスがパフォーマンスをわずかに低下させただけです。私たちの要件では、インデックスを追加する問題は見当たりません。
しかし、これはラボ環境での1つのテストにすぎません。本番データベースでこれを実行するときに他の落とし穴はありますか？特定の状況でINSERTが突然5秒を超える状況に陥ることはありますか？
いいえ、小さな列の基本的なbtreeインデックスは通常、維持するのに安価です。もちろん、テーブルが死んだ行からの膨満を蓄積しているときは少し高価になりますが、その差は小さいはずです。また、インデックス用にディスク上の追加ストレージを検討する必要があります。
言及する価値のあることの1つは、インデックスに関係する列の更新では、H.O.Tを使用できないことです。 updates（ "ヒープのみのタプル"）なので、インデックス付きの列を変更する更新にコストがかかる可能性があります。しかし、それでも、これはone内部最適化を防ぐだけで、大したことはありません。また、更新に列を含める場合にのみ関連します。