web-dev-qa-db-ja.com

Postgres 12：テーブルPARTITION BY（A）のPRIMARY KEY（A、B）とPRIMARY KEY（B、A）の間にパフォーマンスの違いはありますか？

このテーブルを考えると：

_CREATE TABLE tbl (
  a int not null,
  b int not null,
  created timestamp not null default now(),
  primary key(a, b)
) PARTITION BY LIST(a)
_

列aおよびbのルックアップのクエリプランは次のようになります。

_EXPLAIN ANALYZE SELECT EXISTS(SELECT * FROM tbl WHERE a = 1 AND b = 1)

Result  (cost=2.37..2.38 rows=1 width=1) (actual time=0.013..0.013 rows=1 loops=1)
  InitPlan 1 (returns $0)
    ->  Index Only Scan using pkey on partition  (cost=0.15..2.37 rows=1 width=0) (actual time=0.012..0.012 rows=0 loops=1)
          Index Cond: ((a = 1) AND (b = 1))
          Heap Fetches: 0
Planning Time: 0.860 ms
Execution Time: 0.033 ms

_

aによるフィルタリングがすでに行われているため、ルックアップで使用されるインデックスには対象となる列が最初に含まれるため、列の逆順（PRIMARY KEY (b, a) ) PARTITION BY LIST (a)）で主キーを定義するとパフォーマンスが向上するかどうか疑問に思いますクエリプランナーがクエリを実行する単一のパーティションを選択することにより実現されます。

postgresqlindexpostgresql-performancepostgresql-12
3
Tobias Mühl

いいえ、違いはありません。インデックス内の列の順序は、両方の列がWHERE条件で=と比較される場合は重要ではありません（もちろん、条件間にANDがある場合のみ）。

インデックスは、両方の列を同時に使用してスキャンされます。重要なのは、条件に一致するインデックスエントリの数だけで、どちらの場合も同じです。

  a  |  b           b  |  a
-----+-----       -----+-----
   1 |  -1          -1 |   1
   1 |   1  <---    -1 |   2
   1 |   1  <---     1 |   1
   1 |   2           1 |   1  <---
   2 |  -1           1 |   2  <---
   2 |   1           2 |   1
   2 |   3           2 |   3

index on (a,b)   index on (b,a)
1
Laurenz Albe