プランナ／オプティマイザ

　図2および図3では書き換えシステムの工程が記載されています。このステップはPostgreSQLがビューを実装するために採用しているシステムであり、複雑で特殊なため、本稿では飛ばして先に進みます。

　ある与えられたSQL文で、同じ結果をもたらすには多くの方法が存在します。そこで、実行可能な問い合わせ（パス）をすべて検証し、一番早く結果をもたらすものをプラン（問い合わせ実行計画）とします。この工程をコスト（実行時の効率）の見積もりと呼びます。より最適な実行計画を作成するための試行錯誤でテーブルのいろいろなモジュールを組み合わせます。いろいろな結合も検討します。では実際に optimizer/README の一部を読んでみましょう。

　During the planning/optimizing process, we build "Path" trees representing the different ways of doing a query. We select the cheapest Path that generates the desired relation and turn it into a Plan to pass to the executor.

　「プラン作成／オプティマイズ過程で、問い合わせの実行においての異なった方法を表す『パス』木を作成します。目的とするリレーションを生成する最安価のパスを選択し、エクゼキュータに渡すためのプランとします」

　"desired relation"とは「希望する」、もしくは「目的とする」リレーションです。

　(There is pretty much a one-to-one correspondence between the Path and Plan trees, but Path nodes omit info that won't be needed during planning, and include info needed for planning that won't be needed by the executor.)

　「（パスとプラン木間にはまさに1対1の関係がありますが、パスノードはプラン作成時に不必要な情報を除外し、エクゼキュータには必要なく、プラン作成には必要となる情報を追加します）」

　"pretty much"は「まさに」とか「ほとんど」の意味で使われます。

　The optimizer generates optimal query plans by doing a more-or-less exhaustive search through the ways of executing the query. The best Path tree is found by a recursive process:

　「オプティマイザは、程度の差はあってもしらみつぶしで検索を問い合わせの実行により行い、最適問い合わせプランを生成します。最善のパス木はこの工程を繰り返すことにより見いだされます」

　"more-or-less"は「大体」「おおよそ」なので「程度の差はあっても」としてみました。“exhaustive”は「余すところのない」という意味なので「しらみつぶしで」としました。"recursive process"は「繰り返される工程」です。PostgreSQLは最適化手法として「巡回セールスマン問題」を解くのに似た遺伝的アルゴリズムを取り入れています。詳しくはオフィシャルドキュメントを参照してください。

　この見出しの最後として planner.c のコメントから一文を訳出します。

　Set up global state for this planner invocation. This data is needed across all levels of sub-Query that might exist in the given command, so we keep it in a separate struct that's linked to by each per-Query PlannerInfo.

　「プランナ起動の大域的状態の設定。このデータは与えられたコマンド内に存在する可能性のある副問い合わせすべての階層に渡って必要とされるので、それぞれの問い合わせのPlannerInfoにリンクされる個別の構造体に保持します」

　"sub-Query"は「副問い合わせ」で、"sub-Select"とも呼びます。"struct"は "structure"の省略で「構造体」です。

オプティマイザ

　optimazer/READMEの先を読みます。

　The optimizer builds a RelOptInfo structure for each base relation used in the query. Base rels are either primitive tables, or subquery subselects that are planned via a separate recursive invocation of the planner.

　「オプティマイザは問い合わせで使用されるそれぞれの基底リレーションに対し、RelOptInfo構造体を作成します。基底リレーションとはおおもとのテーブルであるか、もしくは独立し、繰り返されるプランナ起動で計画される副問い合わせで得られる結果です」

　A RelOptInfo is also built for each join relation that is considered during planning.

　「RelOptInfoは同時に、計画の過程で検討されるそれぞれの結合リレーションに対しても作成されます」

　Possible Paths for a primitive table relation include plain old sequential scan, plus index scans for any indexes that exist on the table, plus bitmap index scans using one or more indexes.

　「おおもとのテーブルリレーションに対し見込まれるパスはシンプルで長年にわたり使われてきている逐次スキャン、および、テーブル上に存在するあらゆるインデックスに対するインデックススキャン、そして1つ以上のインデックスを使用するビットマップインデックススキャンを含みます」

　"Possible Path"は「可能性のあるパス」、で「見込まれるパス」。

　A subquery base relation just has one Path, a "SubqueryScan" path (which links to the subplan that was built by a recursive invocation of the planner).

　「副問い合わせをベースとしたリレーションは1つのパス、つまり"SubqueryScan"パスを単に所有します（それは繰り返されるプランナ起動で作成される副プランにリンクします）」

　パスの実行時に使用されるスキャンについて説明されています。"sequential scan"、「逐次スキャン」はテーブルを最初から順を追って読んで行く方法です。"index scan"は文字通りインデックスを検索して目的の行を探します。"bitmap index scan"とは、インデックスを検索してから条件を満たした結果のビットマップをメモリ上に生成します。文章内で参照されているように複数のインデックスが存在する場合効率のよい検索結果が求められます。

　次はエクゼキュータについて説明します。