PostgreSQL Index Only Scan 奮闘記 その5

Pocket

どうも。村上です。

今回がきっと最終回の5回目です。

では、最後となる「Index Only Scan 奮闘記」を。

Index Only Scan の explain

前回でもIndex Only Scanの実行計画をみました。
今回は前回より複雑なIndex Only Scanのexplainをみましょう。

テーブルはこんな感じです。

Primary Keyでselect

複合Index

複合Indexの片方

GROUP BY

副問い合わせ

すべてについてIndex Only Scanが使用されましたね。

GOOD

Index Only Scan が効かない!?

usersテーブルの項目を減らしたsimple_usersを作成しました。
データ件数はusersと同じ1000万件です。

このテーブルに対して、Explainしてみます。

あれ???
すべてSeq Scanに!?

vacuum analyzeのし忘れではありません。

Seq ScanをoffにしてExplainしてみると

Index Only Scanが使われるようです。

じゃあ、オプティマイザーがIndex Only Scan より Seq Scanの方が良いと判断したのかな?
コストはSeq Scanの方がよさそうなので、

explain analyzeで速度を見てみましょう。

確かにそれほど速度差はないかな??

でもselect count(*)で見ると

そこそこ速度差はある。。。

ということは列のサイズによってコスト計算がことなり、Index Only Scanが使用されたり、されなかったりする???

ちなみに「Heap Fetches」はテーブルにアクセスした件数です。
今は0件なので、テーブルアクセスなしです。

となります。

vacuum analyzeすると0件になります。

件数を減らすと。。。

不思議なことに件数を減らすとIndex Only Scanが使用されます。

でも件数を増やすと。。。

Index Only Scanが効かない。。。
ってか、Index が効かない??
件数が多い時ほど効いて欲しいんですが。。。

奮闘記は続く

ということで、Index Only Scanを使うには

  • 対象テーブルにIndexを作成する
  • vacuum analyzeをする
  • Indexキーの列だけを参照するselectをする
  • それなりに列のがあるテーブルじゃないと効きません(?)

です。

最後は謎。。。
上記以外にものいろいろ調べましたが、結局謎。。。

おそらくオプティマイザーの仕様がそうなっているんでしょう。
次のバージョンアップはきっと解消されるんでしょう。

その時に、この奮闘記を再び始めます!!

最後になりましたが、この連載を読んでいただいてありがとうございます。
次も連載系のネタがあればやらせていただきますが、しばらくは単発系のネタをするつもりです。

Pocket

Comments are closed, but you can leave a trackback: Trackback URL.