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

第 40章PostgreSQL 内部の概要

目次
40.1. 問い合わせの経路
40.2. 接続の確立
40.3. 構文解析過程
40.3.1. パーサ
40.3.2. 書き換えプロセス
40.4. The PostgreSQL ルールシステム
40.5. プランナ/オプティマイザ
40.6. エクゼキュータ

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

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

40.1. 問い合わせの経路

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

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

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

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

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

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

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

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

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