3

約 30 列、 column a integer not null、b boolean not nullおよびc integer not nullその中にあるテーブルがあります。そして、よく実行されるクエリがありますa = 2 and b is true and c = <something>。

select * from my_table ここで、a = 2、b が真、c = 3215

問題は、次のように部分インデックスに列aを含める必要があるかどうかです。b

索引の作成 idx_my_table_a_b_c
オン my_table
USING btree (a、b、c)
WHERE a = 2 AND b は真です。

または、次のようにすべきではありません：

索引の作成 idx_my_table_a_b_c
オン my_table
btree の使用 (c)
WHERE a = 2 AND b は真です。

最初のケースではexplain出力

「my_table で idx_my_table_a_b_c を使用したインデックス スキャン (コスト = 0.00..8.27 行 = 1 幅 = 4007)」
「索引条件: ((b = true) AND (a = 2))」

そして2番目Index condの部分では不在です

「my_table で idx_my_table_a_b_c を使用したインデックス スキャン (コスト = 0.00..8.27 行 = 1 幅 = 4007)」

ところで とはIndex condどういう意味ですか?

4

2 に答える 2

3

インデックス述語が厳密に等しい場合、述語列をインデックスに含める意味はありません。すべてのインデックス エントリは、列に対して同じ値を持つため、インデックス ルックアップには寄与しません。挿入とルックアップの速度が低下し、インデックスが肥大化するだけです。

于 2012-09-13T15:09:44.507 に答える
1

私の推測(!)は次のとおりです:最初のケース(3列インデックス)では、既存の「インデックス条件」に加えて評価する必要がある列はインデックスの最後にあるため、インデックススキャンは条件を別の方法で評価する必要があります.

2 番目のケース (単一列インデックス) では、where 条件で使用される列 (既に「インデックス付けされた条件」に加えて) がインデックスの先頭の列であり、より効率的に使用できます。

インデックスが同じように動作することを期待(c,a,b)します (3 列のインデックスと比較して順序が異なることに注意してください)。

于 2012-09-13T10:45:09.703 に答える