これらの設定パラメータは、問い合わせオプティマイザが選択する問い合わせ計画に影響する大雑把な手法を提供します。もしも、ある問い合わせに対してオプティマイザが選択したデフォルト計画が最適でない場合、暫定的な解決策は、これらの設定パラメータの1つを使用し、オプティマイザに異なる計画を選択するように仕向けることです。とは言っても、永久にこれらの設定を無効にすることはあまり勧められません。品質を改良する方策は、次のようにしてオプティマイザが選択する計画の品質を向上することです。プランナコスト定数を調節し、ANALYZEをより頻繁に実行し、default_statistics_target設定パラメータの値を大きくし、そしてALTER TABLE SET STATISTICSを使用して、特定の列に対して収集された統計情報を増やします。
enable_bitmapscan（boolean）問い合わせプランナがビットマップ走計画型を選択することを有効もしくは無効にします。デフォルトはonです。
enable_hashagg（boolean）問い合わせプランナがハッシュされた集約計画型を選択することを有効もしくは無効にします。デフォルトはonです。
enable_hashjoin（boolean）問い合わせプランナがハッシュ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。
enable_indexscan（boolean）問い合わせプランナがインデックス走査計画型を選択することを有効もしくは無効にします。デフォルトはonです。
enable_mergejoin（boolean）問い合わせプランナがマージ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。
enable_nestloop（boolean問い合わせプランナが入れ子になったループ結合計画を選択することを有効もしくは無効にします。入れ子ループ結合を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
enable_seqscan（boolean）問い合わせプランナがシーケンシャル査計画を選択することを有効もしくは無効にします。シーケンシャル走査を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
enable_sort（boolean）問い合わせプランナが明示的並び替え手順を選択することを有効もしくは無効にします。明示的並び替えを完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
enable_tidscan（boolean）問い合わせプランナがTID走査計画型を選択することを有効もしくは無効にします。デフォルトはonです。
注意: 残念ながら、以下に紹介する"cost"変数の一群に対する理想的な値を決定する、上手く定義された方法がありません。いろいろ試行して頂き、成果を共有しましょう。
effective_cache_size（floating point）単一インデックス走査に対して有効なディスクキャッシュの実行領域に関するプランナの推測を設定します。これはインデックスを使用するコストの推測要因になります。より高い値はインデックス走査がより使用され、より低い値はシーケンシャル走査が使用されます。このパラメータを設定する場合、PostgreSQLの共有バッファと、PostgreSQLのデータファイルに使用されるカーネルのディスクキャッシュの割合の両方を考慮しなければなりません。同時に、利用可能な領域を共有しますので、異なるインデックスを使用する問い合わせの想定同時実行数も検討してください。このパラメータはPostgreSQLが割り当てた共有メモリーの容量にも、予約されたカーネルディスクキャッシュにも影響を与えません。単に推測のために使用されます。値はディスクページ単位で測定され、通常それぞれ8192バイトで、デフォルトは1000です。
random_page_cost（floating point）順不同でフェッチされるディスクページのコストに対するプランナの推測を設定します。これは順ページフェッチのコストの倍数として測定されます。より高い値を設定すると、シーケンシャルスキャンがより使用されるようになります。より低い値を設定すると、インデックススキャンがより使用されるようになります。デフォルトは4です。
cpu_tuple_cost（floating point）問い合わせ間にそれぞれの行の処理に対するプランナの推測を設定します。これは順番的ページフェッチの分数として測定されます。デフォルトは0.01です。
cpu_index_tuple_cost（floating point）インデックス走査間にそれぞれのインデックス行の処理に対するプランナの推測を設定します。これは順ページフェッチの比率として測定されます。デフォルトは0.001です。
cpu_operator_cost（floating point）WHERE句内のそれぞれの演算子の処理をするプランナの推測を設定します。これは順ページフェッチの比率として測定されます。デフォルトは0.0025です。
geqo（boolean） しらみつぶしの検索を行わないで問い合わせ計画を試みるアルゴリズムである、遺伝的問い合わせ最適化を有効もしく無効にします。デフォルトはオンです。geqo_threshold変数は、ある問い合わせのクラスに対し、GEQOを無効にするよりきめ細かな方法を提供します。
geqo_threshold（integer）少なくともこれだけの数のFROM項目数で問い合わせを計画するのに遺伝的問い合わせ最適化を使用します。（外部JOINの生成子は、1つのFROM項目として計算することに注意してください。）デフォルトは12です。もっと単純な問い合わせでは、決定論的、しらみつぶしの検索プランナを使用するのが最善ですが、多くのテーブルを持つ問い合わせでは、決定論的プランナは非常に時間がかかります。
geqo_effort
（integer）GEQOにおける計画時間と問い合わせ計画の効率性の間のトレードオフを制御します。この変数は1から10までの範囲の整数でなければなりません。デフォルトの値は5です。値を大きくすると、問い合わせ計画作成により多くの時間を費すことになりますが、より効率的な問い合わせ計画が選択される可能性が増加します。
実際geqo_effortは直接何も行いません。それはGEQOの振る舞いに影響を与える他の変数に対し、デフォルトの値を計算するためにのみ使用されます（以下で説明します）。お望みであれば、代わりに手作業で他のパラメータを設定できます。
geqo_pool_size（integer） GEQOで使用されるプール容量を管理します。プール容量とは遺伝的個体群内の個体数です。最低でも2つはなければならず、よく100から1000までの値が使用されます。もし（デフォルトの設定である）零に設定されると、geqo_effortおよび問い合わせの中のテーブル数に基づいて、適切なデフォルトが選択されます。
geqo_generations（integer） GEQOで使用される世代の数を管理します。世代はアルゴリズムの反復数を指定します。最低でも1はなければならず、よくプールサイズと同じ範囲の値が使用されます。これを0に設定（デフォルトの設定）すると、適切なデフォルト値がgeqo_effortに基づいて選択されます。
geqo_selection_bias（floating point）GEQOで使用される淘汰の偏りを管理します。淘汰の偏りは個体群内の（遺伝的な）自然淘汰です。値は1.50から2.00で、2.00がデフォルトです。
default_statistics_target（integer）ALTER TABLE SET STATISTICSで列特定の目的セットを所有していなかったテーブル列に対し、デフォルトの統計対象を設定します。より大きい値はANALYZEに必要なの時間を増加させますが、プランナの予測の品質を向上させます。デフォルトは10です。PostgreSQLの問い合わせプランナによる統計情報の使用法に関するより詳細な情報は、項13.2を参照してください。
constraint_exclusion (boolean)テーブルアクセスを制限するテーブル制限の問い合わせプランナの使用を有効もしくは無効にします。
このパラメータがonの時は、プランナはテーブル CHECK 制約で問い合わせ条件を比較し、制約と矛盾する条件の走査テーブルを削除します。（現在、これは継承走査の子テーブルに対してのみ行われます。）例えば以下の様になります。
CREATE TABLE parent(key integer, ...); CREATE TABLE child1000(check (key between 1000 and 1999)) INHERITS(parent); CREATE TABLE child2000(check (key between 2000 and 2999)) INHERITS(parent); ... SELECT * FROM parent WHERE key = 2400;
制約排除が有効であると、この SELECTは全くchild1000を走査しません。このことは継承が分割されたテーブルの作成に使用される時、性能を向上させます。
現時点でconstraint_exclusionのデフォルトはoffです。その理由は計画がキャッシュされていると間違った結果を返す危険があるからです。もしテーブル制約が変更もしくは削除されると、その前に生成された計画は間違ったものの可能性があり、再計画を強要する組み込まれた機構が存在しません。（この欠陥は将来のPostgreSQLリリースにおいて取り組まれるかも知れません。）これを無効にしておくその他の理由は、制約検査が比較的高価で、多くの場合に救済をもたらさないからです。この機能の長所を利用して設計された分割されたテーブルを実際に使用している方のみ、これを有効にすることをお薦めします。
from_collapse_limit (整数)プランナは、FROMリストがこの数の項目より少ない結果の場合、副問い合わせを上位の問い合わせに併合します。より小さい値は計画時間を縮小させますが、劣った問い合わせ計画をもたらします。デフォルトは8です。通常これをgeqo_threshold以下にしておくと良いでしょう。
join_collapse_limit (整数)最終的にリストがこの値以下になる時、プランナは、明示的な内部JOIN構文をFROM項目のリストに直します。PostgreSQL 7.4以前では、JOIN式で指定された結合は問い合わせプランナで順序の変更は行われませんでした。その後問い合わせプランナが改良され、この形式で記述された内部結合が順序変更できるようになりました。この設定パラメータは、この順序変更を実施するかどうかの程度を制御します。
注意: 現在では、JOIN構文で指定された外部結合の順序は問い合わせプランナによって調整されません。ですから、
join_collapse_limitはこの振る舞いに何の効果も与えません。 PostgreSQLの将来のリリースで外部結合の幾つかのクラスが再順序付けされるように、プランナが改良される可能性があります。
デフォルトでは、この値はfrom_collapse_limitと同じ値に設定されており、殆どの場合に適切です。これを1に設定すると内部JOINの再順序付けは行われなくなります。したがって、問い合わせで指定された明示的結合順序は、関係（リレーション）が結合される実際の順序となります。問い合わせプランナは常に最適な結合順序を選択するとは限りません。上級ユーザなら暫定的にこの変数に1設定し、明示的に希望とする結合順序を指定してもよいでしょう。この変数を1に設定することで他にも、問い合わせプランナがよりPostgreSQL 7.3の問い合わせプランナのような振舞いを行うという効果を得ることができます。後方互換性という理由から有用と考えるユーザもいます。
この変数の値を1とfrom_collapse_limitの間に設定すると、選択された計画の品質に対して計画時間をトレードオフ（値を大きくすることでより良い計画が生成されます）するのに便利です。