Chapter 2. PostgreSQL内部の概略

Table of Contents
2.1. 問い合わせのパス
2.2. 接続の方法
2.3. 構文解析過程
2.4. Postgresルールシステム
2.5. プランナ/オプティマイザ
2.6. エグゼキュータ

著者: この章は、もともとはSimkovics, 1998, Vienna University of Technology においてO.Univ.Prof.Dr. Georg Gottlob と Univ.Ass. Mag. Katrin Seyr.の指導によるStefan Simkovicsの修士論文との 一部として書かれました。

この章はPostgresのバックエンドの内部構造の概略 です。これらのセクションを読めば問い合わせがどのように処理されるかがわか ると思います。詳しい記述は期待しないでください。(Postgres で使われるすべてのデータ構造や関数についてのそのような記述は 1000ページを越えると思います!)この章の目的は、バックエンドで問い合わせを 受け取り結果を返すまでの大まかな制御とデータの流れを理解する手助けをする ことです。

2.1. 問い合わせのパス

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

  1. アプリケーションプログラムからPostgres サーバへ接続する必要があります。アプリケーションプログラムがサーバに 問い合わせを伝え、サーバからの結果を受け取ります。

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

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

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

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

    そのためにはまず同じ結果を得られる全てのパス をつくります。 例えば、もしスキャン対象のリレーション上にインデックスがあった場合、 ふたつのパスが考えられます。一つは単なる順スキャンで、もう一つは インデックスを使ったスキャンです。次にそれぞれの計画を実行するための コストが見積もられ、一番コストの小さいものが選ばれ返されます。

  5. エグゼキュータは再帰的に 計画ツリーを走査し、計画で表されている方法で タプルを検索します。 エグゼキュータはリレーションをスキャンする間ストレージシステム を利用し、ソートと結合を実行します。そして 検索条件 を評価します。 最後に、得られたタプルを返します。

ここからのセクションではPostgresの内部制御と データ構造をよりよく理解するために、ここまでリストしてきた事柄をさらに詳 しく説明します。