行数が少ない場合に、select count(*) でindexを読まない理由を教えてください

Question

各種バージョン

postgres のバージョンは9.5
AWS上のEC2に作成
EC2はCentOS 6.8

テーブル構成

親テーブル A (1億レコードほど)
小テーブル a,b,c,d.... (イベントがあるごとに作る運用となっている。大体500万レコードほど)

それぞれindexの構成は同じ。

小テーブルは親テーブルをパーティションのため継承している。

質問させていただきたいこと

継承によるパーティションがされているテーブルAに対して、
explain analyze select count(*) from A;
を投げた所、小テーブルのScan方法のほとんどが index only scan だったのですが、
とあるテーブルではSeq Scanでした。

そのテーブルは 30行しか入っていません。
（なぜこのような小テーブルがあるのかは謎です。)

select で取得するカラムがあるのであれば、行数が少ないのでindexを読まないという選択があるのはわかります。

しかし、今回はcount(*)なので、行数が少ないにせよindexを読んだほうがほんの少し(本当に少しですが)早いと思います。
テーブルよりもindexのサイズは小さいはずです。

なぜindexを読まないのでしょうか。
30行程度なら「index読もうがテーブル読もうが誤差だ誤差！」みたいな丼勘定なのでしょうか。

Answer 1

テーブルとインデックスが占めるディスクブロック数が同じ(両方とも1)場合は、どちらを利用するか未定です。
プランナで使用される統計情報

Comments

[motisen]

ご回答ありがとうございます。
hihijijiさんの回答も知らなかったです。
勉強になりました。ありがとうございます。

Answer 2

以下が参考になるかと思います。
65.1. 行数推定の例

以下抜粋

非常に簡単な問い合わせから始めましょう。
SELECT * FROM tenk1;
ページ数および行数はpg_classから検索されます。
これらの値は最後にそのテーブルをVACUUMまたはANALYZEを行った時点のものです。 プランナはその後、テーブル内の実際のページ数を取り出します（これはテーブルスキャンを行わない安価な操作です）。 それがrelpagesと異なる場合、reltuplesを得られたページ数の割合に応じて変更して現在の推定行数を求めます。

where条件の無いCount(*)で件数を求める場合、先ずは「テーブルスキャンを行わない安価な操作」が行われます。この状況のみで件数を取得した場合には、実行計画はindex scan にはなりません。

Comments

[motisen]

ご回答ありがとうございます。テーブルスキャンを行わない安価な操作などで実際のページ数と取り出しているとは・・・。知りませんでした。ありがとうございます。

Answer 3

極端に小さなテーブルだと、メモリに全テーブルが乗っている（けどインデックスはメモリにない）ので、「わざわざインデックスを呼び出すより、テーブルを全部読むほうが速い」となる状況があるのかもしれません。

Comments

[motisen]

ご回答ありがとうございます。
selct count(*) したあとに、explain analyze select count(*) していました。
確かにメモリ（キャッシュ）に乗ってそうです。今後はそのあたりも考えて計測したいと思います。