【PostgreSQL】enable_seqscan について検証してみた (その2)

こんにちは。サイオステクノロジー OSS サポート担当 Y です。

今回は、PostgreSQL の enable_seqscan を off にした際の処理について調査を行なってみました。(※以下の内容は CentOS 7.6/PostgreSQL 11.1 にて検証しています。)

■はじめに

前回は、ドキュメントに記載されている “enable_seqscan を off にしても、シーケンシャルスキャンを完全に無効にすることはできない” という内容について検証を行いました。

結果として、ドキュメントに記載されている通りシーケンシャルスキャンを完全に無効にすることはできない (enable_seqscan = off であっても、シーケンシャルスキャンが実行されることがある) ことを確認できました。

今回は、この “完全に無効にすることはできない” 部分の仕組みを少し深掘りしてみようかと思います。

■調査

ということで、仕組みの詳細を深掘りするためにソースコードを調べてみようと思います。

今回調査の対象となる enable_seqscan の設定値は、プログラムの内部でも同名の変数 enable_seqscan に格納されて利用されているようです。

この変数 enable_seqscan が利用されている箇所を探してみると、以下の様な処理を発見しました。

enable_seqscan = off の設定 (変数 enable_seqscan の値が false) の場合、”startup_cost += disable_cost” という計算が実施されています。

また、(かなり大雑把な説明にはなってしまいますが) この startup_cost 等の値を使って、最終的な実行計画のコストが計算されるようです。

上記ソースコードを見てみると、enable_seqscan の on/off によって処理が分岐し、この “コストの計算” の部分 (コストの計算結果) が変わる仕組みになっているようです。

この計算に使われている disable_cost の値は以下の様に定義されていました。1.0e10 = 10000000000 なので、前回の検証で出力されていた “cost=10000000000.00″ という内容とも合致しているようです。

上記より、”enable_seqscan = off” が設定されている場合 “シーケンシャルスキャンを行う実行計画のコストを大きくする” という処理が実行されるようです。

PostgreSQL は、クエリを実行する際に実行可能な複数の実行計画のコストを計算し、基本的に最もコストが低い実行計画を選んでその実行計画でクエリを実行します。

つまり、”enable_seqscan = off” の場合 “シーケンシャルスキャンを行う実行計画のコストが大きくなる” ため、シーケンシャルスキャンが選択されにくくなるという動作になるようです。

■まとめ

ソースコードを読んでみたところ、”enable_seqscan = off” に設定しても “シーケンシャルスキャンを利用する実行計画のコストが大きくなる” だけであり、”他の実行計画のコストの方が大きい場合” や “シーケンシャルスキャン以外の選択肢 (実行計画) が無い場合” には、シーケンシャルスキャンが実行される作りになっているようです。

これが、今回調査しようとしていた “シーケンシャルスキャンを完全に無効にはできない” という部分の仕組み (理由) のようです。

>> 雑誌等の執筆依頼を受付しております。
   ご希望の方はお気軽にお問い合わせください!

ご覧いただきありがとうございます! この投稿はお役に立ちましたか?

役に立った 役に立たなかった

0人がこの投稿は役に立ったと言っています。

コメント投稿

メールアドレスは表示されません。


*