2011年7月17日

[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@xxxxx 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)
>
>
>
> 以上、よろしくお願い致します。
>
>


投稿者 xml-rpc : 2011年7月17日 17:14
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/105256
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。