PostgreSQLの単一対最適化SELECTパフォーマンスのためのマルチカラムインデックス付け

Question

私はPostgreSQL、特にそのパフォーマンスチューニングの新機能を使用しています。基本的には、segmentSize（範囲1〜10）、segmentX（範囲+/- 100,000）、segmentY（範囲+/- 100,000）の3つの整数値を照会することによってアクセスされるデータがあります。

データボリュームが大きくなると、データを複数のテーブルに分割したり、個々のsegmentSizeごとに1つずつ、および/またはsegmentXとsegmentYの連続した範囲に分割する可能性があります。

現在の選択：キー（segmentSize、segmentX、segmentY）を直接使用するか、パフォーマンスを向上させるために、PostgreSQLの外でsegmentX、segmentYを単一の整数に結合する合成キーを作成します（segmentSize、segmentX、segmentY）

質問：セグメントXからのこの "結合キー"派生のコストについてあまり心配していないと仮定すると、セグメントYが発生しますPosterの外で、パフォーマンスの違いが生じない限り、データの1行あたりのバイト数のオーダーで特別にスペースを確保していないとしたら、 ....罪segmentXとsegmentYの2つの別々のint値の組み合わせを照会するのとは対照的に、segmentX * segmentYの範囲のint値を返すか？

多くの方々に感謝します。 SELECT /読み取りのパフォーマンスを最大限に高めるために、該当するデータとインデックス作成戦略を拡張するリンクを含めてください。

Answer 1

2つ（または3つ）の列をキーの単一の値に組み合わせることによるパフォーマンスのメリットは、ごくわずかです。それは実際にいくつかの用途のためにのパフォーマンスを傷つける可能性があります。これらの値が他のテーブルで意味を持つ場合、合成キーを「ナビゲート」する必要があるため、より高速なプランが考慮されません。利用可能な自然キーがあるときに合成キーを使用することは、それが実際に物事を遅くする可能性が高いことを含めて、それに関連するすべてのリスクを伴う「早すぎる最適化」という見出しの下にある傾向があります。