[pgsql-jp: 40861] Re: PostgreSQLにおける複合PKと複合INDEXの選択基準

[川田 寛]

野沢さん


川田です。

実行計画最適化のフェーズについて詳細は解りかねる上、
データの分布についても把握していないため、
あまり的確なアドバイスが出来かねますが、、、
頂いた情報のみで判断した場合、、、

現在idx_t_z_02は、a→b→dの順で宣言されていると思いますが、
これをa→c→bの順で宣言。

idx_t_z_02の索引はa→bのパスを経由できなくなるため、
必然的に主キーの索引(a→b→c)を使うことになると思います。

---
板垣様から索引サイズの確認というアドバイスがありましたが、
私も以前試したことがあります。

今回のケースのような、索引指定されたカラムの型、数、が同じの場合、
索引ファイルのサイズが同じになりました。
10万レコードほど登録しanalyzeしても、
最適と考えられる索引が選択されず、野沢さんと同じような状態に陥りました。

PostgreSQLの索引の作りについては、
コードを読んでいないため今の所把握していませんが、
今回のようなケースにおいて、
索引選択のミスに繋がることがあると、私は認識しています。
# 以前同じような問題で悩まされたことがあります。

お詳しいかたがいれば、是非アドバイスいただきたいところですが。


以上、共有でした。

(2011/07/14 22:14), nozawakz ＠ nttdata.co.jp wrote:
> お世話になっております。野沢と申します。
> 
> 
> PostgreSQLにおける複合PKと複合INDEXの選択基準について
> 質問させてください。
> 
> 下記のSQL（※）では、第1PK、第2PK、第3PKで一意に絞り込まれるため、複合PK（pk_t_z）を使っての実行計画が選択されることを
> 期待していたのですがExplain文で取得みると複合INDEX（idx_t_z_02）の方が選択されておりました。
> 
> PostgreSQLではHOTの「インデックス・エントリの追加をスキップ」する機能があるため、
> 優先的に複合PKよりも複合INDEXが選択されるのでしょうか。
> PostgreSQLにおける複合PKと複合INDEXの選択基準があれば合わせてご教授ください。
> 
> Explain対象SQL、実行計画、実行時INDEX情報は下記のとおりです。
> 
> ※[Explain対象SQL]
>          SELECT
>              a,
>              b,
>              c,
>          FROM t_z
>          WHERE a = CAST(:subscriberId AS BIGINT)
>              AND c = CAST(:detailsSnum AS INTEGER)
>              AND b = :serviceContactId
>              AND e = 'n';
> 
> [実行計画]
>   Index Scan using idx_t_z_02 on t_z  (cost=0.00..8.47 rows=1 width=505) (actual time=74.420..74.421 rows=1 loops=1)
>     Index Cond: ((a = 86129::bigint) AND (b = '10086063       '::bpchar))
>     Filter: ((c = 1) AND (e = 'n'::bpchar))
>   Total runtime: 74.490 ms
> (4 行)
> 
> [実行時INDEX情報]
> インデックス:
>      "pk_t_z" PRIMARY KEY, btree (a, b, c)
>      "idx_t_z_01" btree (b)
>      "idx_t_z_02" btree (a, b, d)
> 
> 
> 
> 以上、よろしくお願い致します。
> 
>