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

第 42章PostgreSQL 内部の概要

目次
42.1. 問い合わせの経路
42.2. 接続の確立
42.3. 構文解析過程
42.3.1. パーサ
42.3.2. 書き換えプロセス
42.4. The PostgreSQL ルールシステム
42.5. プランナ/オプティマイザ
42.6. エクゼキュータ

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

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

42.1. 問い合わせの経路

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

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

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

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

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

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

    そのためにまず同じ結果をもたらすすべての可能なかぎりの経路を作ります。たとえば、スキャンの対象となるリレーション上にインデックスがあるとすると 2 つの経路があります。1 つは単純な逐次スキャンで、もう 1 つはインデックスを使ったスキャンです。つぎにそれぞれの計画を実行するためのコストが見積もられ、一番コストの小さい計画が選ばれて返されます。

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

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