[pgsql-jp: 41928] Re: 【返信:質問】サブクエリを使った検索文の実行時間短縮について

Tsunakawa, Takayuki tsunakawa.takay @ jp.fujitsu.com
2017年 3月 29日 (水) 14:41:38 JST


綱川といいます。

>  ここで疑問なのですが、なぜ、ここが、Bitmap Heap Scan なのでしょうか。
> 検索で使っている video も content もインデックスがついています。
> なぜ、Index Scan でないのでしょうか。

このような説明があります。

https://www.postgresql.org/docs/devel/static/using-explain.html

Here the planner has decided to use a two-step plan: the child plan node visits an index to find the locations of rows matching the index condition, and then the upper plan node actually fetches those rows from the table itself. Fetching rows separately is much more expensive than reading them sequentially, but because not all the pages of the table have to be visited, this is still cheaper than a sequential scan. (The reason for using two plan levels is that the upper plan node sorts the row locations identified by the index into physical order before reading them, to minimize the cost of separate fetches. The “bitmap” mentioned in the node names is the mechanism that does the sorting.)

つまり、検索条件に該当する行がたくさんありそうだからでしょう。
Index Scanによりインデックスで該当レコードを1件見つけるごとにテーブルから読むと、
テーブルへのランダムアクセスが多くなります。
それよりも、Bitmap Index Scanでインデックスから該当レコードのTIDをまとめて取り出し、
Bitmap Heap ScanでそのTIDをディスク上のブロック順に並べてからTIDごとにテーブルを読めば、
ディスクのシーク時間も減って速くなる、とプランナが考えたのだと思います。


以上です。



pgsql-jp メーリングリストの案内