プランナ/オプティマイザの役割は、最適な実行計画を作ることです。ある与えられた SQL 問い合わせ（それがある問い合わせツリーになるのですが）あらゆる異なった方法で実際には実行され、それぞれの手順は同じ結果をもたらします。もしもコンピュータの演算として可能であれば問い合わせオプティマイザは全ての可能な実行プランを検証し、実行するとした場合に一番早く結果をもたらす実行計画を選択するでしょう。
注意: 場合によっては問い合わせをどう実行するかの選択を検証するために膨大な時間とメモリー空間を消費する可能性があります。特に規模の大きな結合操作に問い合わせが係わった時などです。ほどよい時間内でほどよい（最適ではありません）問い合わせ計画を決定するために PostgreSQL は 遺伝的問い合わせ最適化 を使用します。
最も安価である過程が決定されたあと計画ツリーが作成されてエクゼキュータに渡されます。ということは要求されている実行計画はエクゼキュータがそれを実行するために充分な詳しい内容を所有していることを表しています。
プランナ/オプティマイザは、問い合わせの中に現れるリレーションで定義されるインデックスの型に基づいて、どのプランが作られるべきかを決めます。リレーション上で逐次スキャンを行う可能性は常に考えられるため、逐次スキャンのみを使ったプランが例外なく作成されます。リレーション上にインデックス（たとえば B-tree インデックス）が定義され、問い合わせには制約 relation.attribute OPR constant があるとしましょう。もし relation.attribute が B-tree インデックスのキーと一致し OPR がインデックスの 演算子クラス にリストされている演算子の一つであれば、リレーションをスキャンする別の計画が B-tree インデックスを使って作られます。さらに他のインデックスが存在し、問い合わせの中で制約がインデックスのキーに一致した場合、なおその上に計画が検討されます。
単一のリレーションをスキャンする可能性があるすべての計画が見つかると、リレーションを結合するための計画が作られます。プランナ/オプティマイザは WHERE 制約のなかで一致する結合句が存在するすべての 2 つのリレーション（例えばそれに対して where rel1.attr1=rel2.attr2 のような制約が存在する場合）を選択して考慮します。結合制約のない結合の組み合せはほかに選択の余地がない場合のみ考慮されます。つまり、ある特定のリレーションはほかのいかなるリレーションにたいして有効な結合句を所有しない場合です。プランナ/オプティマイザに考慮された結合の組にはすべての実行可能な計画が作られます。3 つの実行可能な結合戦略です。
入れ子反復結合： 左側のリレーションのなかで見つけられた行ごとに右側のリレーションが 1 回スキャンされます。 この戦略は実装が簡単ですが、時間がかかる場合があります。（とは言っても右側のリレーションがインデックススキャンによってスキャン可能であればよい戦略になります。右側のインデックススキャンのキーとして左側のリレーションの現在の行の値を使用することができます。）
マージソート結合：結合を開始する前に、それぞれのリレーションが結合属性でソートされます。そして 2 つのリレーションは両方とも結合属性で並んでいるという前提でマージされます。それぞれのリレーションがたった 1 回しかスキャンされなくて済むのでこの結合は魅力的です。
ハッシュ結合:右側のリレーションがハッシュキーとして結合属性を用いて初めにスキャンされ、ハッシュテーブルに読み込まれます。次に左側のリレーションがスキャンされ、見つかったそれぞれの行にふさわしい値が、右側のリレーションの行を捜し出すためのハッシュキーとして使われます。
最終的な計画ツリーは基になっているリレーションの逐次もしくはインデックススキャン、そして必要に応じて入れ子ループ、マージ、またはハッシュ結合のノード、さらにはソートまたは集約関数計算ノードのような必要とされる補助の手順から構成されます。これらほとんどの計画ノード型は選択（特定の理論演算条件に合致しない行を破棄すること）および射影（与えられた列の値に基づき派生した列の集合を計算すること、つまり必要なところでスカラ式の評価をすること）を行う追加的能力を持っています。プランナの一つの責任として WHERE 句から選択条件を付加して計画ツリーのもっとも適切なノードにたいし必要とされる出力式を計算することです。