他のバージョンの文書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

第 41章PostgreSQL内部の概要

目次
41.1. 問い合わせの経路
41.2. 接続の確立
41.3. 構文解析過程
41.3.1. パーサ
41.3.2. 書き換えプロセス
41.4. PostgreSQLルールシステム
41.5. プランナ/オプティマイザ
41.6. エクゼキュータ

著者: 本章はEnhancement of the ANSI SQL Implementation of PostgreSQLとして、 ウィーン工科大学にてO.Univ.Prof.Dr. Georg GottlobとUniv.Ass.Mag. Katrin Seyr.の指導の下にStefan Simkovicsが書いた修士論文の一部が基になっています。

本章ではPostgreSQLのバックエンドの内部構造の概要を説明します。 次からの節を読んだ後には、問い合わせがどのように処理されるかの概念がつかめているはずです。 ここではPostgreSQLの内部操作の詳細な説明は行いません。 記述するとしたら文章が膨大になってしまうからです。 どちらかと言えば、バックエンドが問い合わせを受け取った時点からクライアントに結果を返す時点の間に引き起こる操作の一般的な流れを理解してもらうのが目的です。

41.1. 問い合わせの経路

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

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

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

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

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

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

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

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

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