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

Chapter 2. PostgreSQL 内部の概要

Table of Contents
2.1. 問い合わせの過程
2.2. 接続の確立
2.3. 構文解析過程
2.3.1. パーサー
2.3.2. 書き換えプロセス
2.4. The PostgreSQL ルールシステム
2.5. プランナ/オプティマイザ
2.5.1. 実行可能な計画の生成
2.5.2. 計画のデータ構造
2.6. エクゼキュータ

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

この章では PostgreSQL のバックエンドの内部構造の概要を説明します。つぎの節を読んだあとには、問い合わせがどのように処理されるかの概念が掴めているはずです。ここで詳しい記述は期待しないでください(PostgreSQLで使われるすべてのデータ構造や関数について詳細に解説すると 1,000 ページを越えてしまうでしょう!)。この章は、バックエンド内で問い合わせを受け取ってから結果を返すまでの一般的な制御とデータの流れの理解に役立たせる目的のものです。

2.1. 問い合わせの過程

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

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

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

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

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

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

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

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

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