Here we give a short overview of the stages a query has to pass to obtain a result. ここでは、問い合わせが結果を得るためにたどる過程を簡単に説明します。
A connection from an application program to the <productname>PostgreSQL</productname> server has to be established. The application program transmits a query to the server and waits to receive the results sent back by the server. アプリケーションプログラムからPostgreSQLサーバに接続が確立されなくてはなりません。 アプリケーションプログラムはサーバに問い合わせを送り、そしてサーバから送り返される結果を待ちます。
The <firstterm>parser stage</firstterm> checks the query transmitted by the application program for correct syntax and creates a <firstterm>query tree</firstterm>. 構文解析過程で、アプリケーションプログラムから送られた問い合わせの構文が正しいかをチェックし、問い合わせツリーを作成します。
The <firstterm>rewrite system</firstterm> takes the query tree created by the parser stage and looks for any <firstterm>rules</firstterm> (stored in the <firstterm>system catalogs</firstterm>) to apply to the query tree. It performs the transformations given in the <firstterm>rule bodies</firstterm>. 書き換えシステムは構文解析過程で作られた問い合わせツリーを受け取り、問い合わせツリーに適用するための(システムカタログに格納されている)ルールを探します。 そしてルール本体で与えられた変換を実行します。
One application of the rewrite system is in the realization of <firstterm>views</firstterm>. Whenever a query against a view (i.e., a <firstterm>virtual table</firstterm>) is made, the rewrite system rewrites the user's query to a query that accesses the <firstterm>base tables</firstterm> given in the <firstterm>view definition</firstterm> instead. 書き換えシステムの適用例の1つとしてビューの具現化が挙げられます。 ビュー(すなわち仮想テーブル)に対して問い合わせがあると、書き換えシステムが代わってユーザの問い合わせを、ビュー定義で与えられた実テーブルにアクセスする問い合わせに書き換えます。
The <firstterm>planner/optimizer</firstterm> takes the (rewritten) query tree and creates a <firstterm>query plan</firstterm> that will be the input to the <firstterm>executor</firstterm>. プランナ/オプティマイザは、(書き換えられた)問い合わせツリーを見て、エグゼキュータに渡すための問い合わせ計画を作ります。
It does so by first creating all possible <firstterm>paths</firstterm> leading to the same result. For example if there is an index on a relation to be scanned, there are two paths for the scan. One possibility is a simple sequential scan and the other possibility is to use the index. Next the cost for the execution of each path is estimated and the cheapest path is chosen. The cheapest path is expanded into a complete plan that the executor can use. そのためにまず同じ結果をもたらす全ての可能な限りの経路を作ります。 例えば、スキャンの対象となるリレーション上にインデックスがあるとすると2つの経路があります。 1つは単純なシーケンシャルスキャンで、もう1つはインデックスを使ったスキャンです。 次にそれぞれの経路を実行するためのコストが見積もられ、一番コストの小さい経路が選ばれます。 一番コストの小さな経路は、エグゼキュータが実行できるように完全な計画に拡張されます。
The executor recursively steps through the <firstterm>plan tree</firstterm> and retrieves rows in the way represented by the plan. The executor makes use of the <firstterm>storage system</firstterm> while scanning relations, performs <firstterm>sorts</firstterm> and <firstterm>joins</firstterm>, evaluates <firstterm>qualifications</firstterm> and finally hands back the rows derived. エグゼキュータは再帰的に計画ツリー上を進み、計画で示されている方法で行を抽出します。 エグゼキュータはリレーションをスキャンする間保存システムを利用してソートと結合を実行し、検索条件の評価を行い、最後に得られた行を返します。
In the following sections we will cover each of the above listed items in more detail to give a better understanding of <productname>PostgreSQL</productname>'s internal control and data structures. これからの節では、PostgreSQLの内部制御とデータ構造をより良く理解するために、上に記載した事柄をさらに詳しく説明します。