4

私は PostgreSQL、特にパフォーマンス チューニングの面で初めてです。基本的に、次の 3 つの整数値を照会することによってアクセスされるデータがあります。

将来を見据えた考慮事項: データ ボリュームが大きくなると、データを複数のテーブル (個々の segmentSize ごとに 1 つ)、および / またはセグメント X とセグメント Y の連続した範囲に分割する可能性があります。

現在の選択: キー (segmentSize、segmentX、segmentY) を直接使用するか、パフォーマンスを向上させるために、PostgreSQL の外部で、segmentX、segmentY を単一の整数値に結合する合成キーを作成するアーキテクチャ上の選択があります。キー (または可能性は低いですが、3 つすべて (segmentSize、segmentX、segmentY))。

質問: セグメント X からのこの「結合されたキー」導出のコストについてあまり心配していないと仮定すると、セグメント Y は Postgress の外部で発生し、データの行あたりのバイト数のオーダーでスペースを節約した後ではないことを考えると (それはパフォーマンスの違いを生みます), .... セグメント X とセグメント Y の 2 つの個別の int 値の組み合わせをクエリするのではなく、範囲 segmentX * segmentY の単一の int 値をクエリすることで、測定可能なまたは意味のあるパフォーマンスの向上がありますか? ?

大変感謝します。選択/読み取りのパフォーマンスを最大化するために、該当するデータとインデックス作成戦略を展開するリンクを自由に含めてください。

4

1 に答える 1

1

2 つ (または 3 つ) の列をキーの 1 つの値に結合することによるパフォーマンス上の利点は、おそらくごくわずかです。実際には、一部の使用法ではパフォーマンスが低下する可能性があります。これらの値が他のテーブルで意味がある場合、合成キーを「ナビゲート」する必要があるため、より高速なプランを検討できなくなります。利用可能な自然キーがあるときに合成キーを使用することは、「時期尚早の最適化」の見出しに該当する傾向があり、それに関連するすべてのリスクがあります。これには、実際に処理が遅くなる可能性が高いことも含まれます。

于 2012-04-04T18:24:35.213 に答える