※ ChatGPTを利用し、要約された質問です（原文：indexを使おうとしない間違ったcost計算）
index検索が遅い理由とは？
このQ&Aのポイント
テーブルの抽出結果が思ったよりも遅い場合、indexの使用を考慮してください。
indexはデータの特定の列に対して高速な検索を可能にするためのデータ構造です。
しかし、適切なindexが作成されていない場合や、データの分布が偏っている場合、indexの使用によってパフォーマンスが悪化する可能性があります。
postgres 7.2.4で質問させてください。
以下のような構成のテーブルの抽出をしようとしています。
テーブル名 ：t_name
カラム名 ：k1、k2、k3
インデックス：t_name_idx
テーブルt_nameの全体件数は約70万件で、上記のSQLから期待
される抽出結果件数は約1万5千件です。t_nameにはk3のみを対象としたインデックス、t_name_idxが作成してあります。次のようなSQLを実行した際に、シーケンス検索になり応答までに６秒ほどかかってしまいます。
select k1,k2 from t_name where k3 in ("100","200");
explain analyzeで実行計画を見ると
(cost=26.29..15304.62 rows=523 width=104)
Total runtime: 6427.32 msec
です。シーケンスをSET enable_seqscan TO off; で使用しないようにして、強制的にt_name_idxを使うと次のような結果になります。
(cost=0.00..42009.05 rows=523 width=104)
Total runtime: 423.81 msec
実際にはindexを使用したほうが10倍以上も速いのに、プランナはシーケンス検索のほうがコストが小さいと判断しています。何故このようになってしまうのでしょうか？VACUUM ANALYZEを行っても結果は変わりませんでした。
私のイメージでは、index検索のほうがコストが小さく計算されて、それを使うべき。というイメージなのですが、考え方自体が間違っているのでしょうか？
原因を調べ始めて１週間経ち、行き詰っています。
どなたかヒントだけでもいいので教えてください。
お礼
お礼が遅くなり、申し訳ありません。 ＞(1)7.2ではvacuum,analyzeに加えreindexも必要、一度すべて試行し ＞てからEXPLAINをしてみる。 reindexは初耳でした、少し調べてから使用して問題なさそうならやってみます。 ＞(2)7.2ではIN関数が不得意なので ＞ where k3='100' or k3='200'・・・ ＞に置き換えるか、PGversionを8.2などに上げてみる inのほうが速いと思っていたのですが、違うのですね。 PGversionは保守の観点からむやみに変更できないので、（１）を試してみます。ありがとうございました。