他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

44.1. 問い合わせの経路

ここでは、問い合わせが結果を得るためにたどる過程を簡単に説明します。

  1. アプリケーションプログラムからPostgreSQLサーバに接続が確立されなくてはなりません。 アプリケーションプログラムはサーバに問い合わせを送り、そしてサーバから送り返される結果を待ちます。

  2. 構文解析過程で、アプリケーションプログラムから送られた問い合わせの構文が正しいかをチェックし、問い合わせツリーを作成します。

  3. 書き換えシステムは構文解析過程で作られた問い合わせツリーを受け取り、問い合わせツリーに適用するための(システムカタログに格納されている)ルールを探します。 そしてルール本体で与えられた変換を実行します。

    書き換えシステムの適用例の1つとしてビューの具現化が挙げられます。 ビュー(すなわち仮想テーブル)に対して問い合わせがあると、書き換えシステムが代わってユーザの問い合わせを、ビュー定義で与えられた実テーブルにアクセスする問い合わせに書き換えます。

  4. プランナ/オプティマイザは、(書き換えられた)問い合わせツリーを見て、エクゼキュータに渡すための問い合わせ計画を作ります。

    そのためにまず同じ結果をもたらす全ての可能な限りの経路を作ります。 例えば、スキャンの対象となるリレーション上にインデックスがあるとすると2つの経路があります。 1つは単純なシーケンシャルスキャンで、もう1つはインデックスを使ったスキャンです。 次にそれぞれの経路を実行するためのコストが見積もられ、一番コストの小さい経路が選ばれます。 一番コストの小さな経路は、エクゼキュータが実行できるように完全な計画に拡張されます。

  5. エクゼキュータは再帰的に計画ツリー上を進み、計画で示されている方法で行を抽出します。 エクゼキュータはリレーションをスキャンする間保存システムを利用してソート結合を実行し、検索条件の評価を行い、最後に得られた行を返します。

これからの節では、PostgreSQLの内部制御とデータ構造をより良く理解するために、上に記載した事柄をさらに詳しく説明します。