これらの設定パラメータは、問い合わせオプティマイザが選択する問い合わせ計画に影響する大雑把な手法を提供します。もしも、ある問い合わせに対してオプティマイザが選択したデフォルト計画が最適でない場合、暫定的な解決策は、これらの設定パラメータの1つを使用し、オプティマイザに異なる計画を選択するように仕向けることです。とは言っても、永久にこれらの設定を無効にすることはあまり勧められません。品質を改良する方策は、次のようにしてオプティマイザが選択する計画の品質を向上することです。プランナコスト定数を調節し、ANALYZEをより頻繁に実行し、default_statistics_target設定パラメータの値を大きくし、そしてALTER TABLE SET STATISTICSを使用して、特定の列に対して収集された統計情報を増やします。
問い合わせプランナがビットマップ走計画型を選択することを有効もしくは無効にします。デフォルトはonです。
問い合わせプランナがハッシュされた集約計画型を選択することを有効もしくは無効にします。デフォルトはonです。
問い合わせプランナがハッシュ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。
問い合わせプランナがインデックス走査計画型を選択することを有効もしくは無効にします。デフォルトはonです。
問い合わせプランナがマージ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。
問い合わせプランナが入れ子になったループ結合計画を選択することを有効もしくは無効にします。入れ子ループ結合を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
問い合わせプランナがシーケンシャル査計画を選択することを有効もしくは無効にします。シーケンシャル走査を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
問い合わせプランナが明示的並び替え手順を選択することを有効もしくは無効にします。明示的並び替えを完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトはonです。
問い合わせプランナがTID走査計画型を選択することを有効もしくは無効にします。デフォルトはonです。
本節で扱うコスト変数は、任意の尺度で測られます。 これらは相対的な値でしかありません。 そのため、同じ因子で尺度を変えても、プランナの選択は結果として変わりません。 伝統的に、これらの変数はコスト単位としてシーケンシャルなページ取り込みを参照していました。 つまり、seq_page_costを慣習的に1.0とし、他のコスト変数をそれを参考にして設定されていました。 しかし望むなら、特定のマシンにおけるミリ秒単位の実行時間など、異なる尺度を使用することができます。
注意: 残念ながら、コスト変数に対する理想的な値を決定する、上手く定義された方法がありません。 特定のインストレーションが行うだろう問い合わせ全体を混在させたものの平均を最善のものとして扱われています。 数回の実験のみを根拠にこの値を変更することは危険であるといえます。
シーケンシャルな一連の取り出しの一部となる、ディスクページ取り出しに関する、プランナの推定コストを設定します。 デフォルトは1.0です。
非シーケンシャルに取り出されるディスクページのコストに対するプランナの推測を設定します。 デフォルトは4です。 この値をseq_page_costに相対的に減少させると、システムはインデックススキャンを好んで使用するようになります。 増加させると、インデックススキャンが相対的に高価になります。 両方の値を増減させることで、CPUコストに対するディスクI/Oの重要性を変更させることができます。 これについては、後述のパラメータで説明します。
ティップ: システムはrandom_page_costをseq_page_costよりも小さな値に設定しようとしますが、これには物理的な意味はありません。 しかし、データベースが完全にRAMにキャッシュされる場合、同じ値に設定することは意味を持ちます。 この場合、順序通りではないページアクセスに対するペナルティが存在しないからです。 また、多くがキャッシュされるデータベースでは、CPUパラメータに対して両値を小さく設定すべきです。 RAM内に存在するページの取り出しコストは通常よりもかなり小さくなるためです。
問い合わせ間にそれぞれの行の処理に対するプランナの推測を設定します。デフォルトは0.01です。
インデックス走査間にそれぞれのインデックス行の処理に対するプランナの推測を設定します。 デフォルトは0.005です。
問い合わせ時に実行される各演算子や関数の処理コストに対するプランナの推測を設定します。デフォルトは0.0025です。
単一の問い合わせで利用できるディスクキャッシュの実効容量に関するプランナの仮定を設定します。 これは、インデックスを使用するコスト推定値の要素となります。 より高い値にすれば、よりインデックススキャンが使用されるようになり、より小さく設定すれば、シーケンシャルスキャンがより使用されるようになります。 このパラメータを設定する時には、PostgreSQLの共有バッファとPostgreSQLデータファイルに使用されるカーネルのディスクキャッシュの量の両方を考慮しなければなりません。 また、利用可能な領域を共有しますので、異なるテーブルに対して同時に実行される問い合わせの総定数も考慮してください。 このパラメータは、PostgreSQLで割り当てられる共有メモリの大きさには影響を与えません。また、カーネルのディスクキャッシュを予約したりもしません。 これは推定目的のみで使用されます。 デフォルトは128メガバイト（128MB）です。
しらみつぶしの検索を行わないで問い合わせ計画を試みるアルゴリズムである、遺伝的問い合わせ最適化を有効もしく無効にします。デフォルトはオンです。geqo_threshold変数は、ある問い合わせのクラスに対し、GEQOを無効にするよりきめ細かな方法を提供します。
少なくともこれだけの数のFROM項目数で問い合わせを計画するのに遺伝的問い合わせ最適化を使用します。 （FULL OUTER JOINの生成子は、1つのFROM項目として計算することに注意してください。）デフォルトは12です。もっと単純な問い合わせでは、決定論的、しらみつぶしの検索プランナを使用するのが最善ですが、多くのテーブルを持つ問い合わせでは、決定論的プランナは非常に時間がかかります。
GEQOにおける計画時間と問い合わせ計画の効率性の間のトレードオフを制御します。この変数は1から10までの範囲の整数でなければなりません。デフォルトの値は5です。値を大きくすると、問い合わせ計画作成により多くの時間を費すことになりますが、より効率的な問い合わせ計画が選択される可能性が増加します。
実際geqo_effortは直接何も行いません。それはGEQOの振る舞いに影響を与える他の変数に対し、デフォルトの値を計算するためにのみ使用されます（以下で説明します）。お望みであれば、代わりに手作業で他のパラメータを設定できます。
GEQOで使用されるプール容量を管理します。プール容量とは遺伝的個体群内の個体数です。最低でも2つはなければならず、よく100から1000までの値が使用されます。もし（デフォルトの設定である）零に設定されると、geqo_effortおよび問い合わせの中のテーブル数に基づいて、適切なデフォルトが選択されます。
GEQOで使用される世代の数を管理します。世代はアルゴリズムの反復数を指定します。最低でも1はなければならず、よくプールサイズと同じ範囲の値が使用されます。これを0に設定（デフォルトの設定）すると、適切なデフォルト値がgeqo_effortに基づいて選択されます。
GEQOで使用される淘汰の偏りを管理します。淘汰の偏りは個体群内の（遺伝的な）自然淘汰です。値は1.50から2.00で、2.00がデフォルトです。
ALTER TABLE SET STATISTICSで列特定の目的セットを所有していなかったテーブル列に対し、デフォルトの統計対象を設定します。より大きい値はANALYZEに必要なの時間を増加させますが、プランナの予測の品質を向上させます。デフォルトは10です。PostgreSQLの問い合わせプランナによる統計情報の使用法に関するより詳細な情報は、項13.2を参照してください。
問い合わせを最適化するためのテーブル制限の問い合わせプランナの使用を有効もしくは無効にします。 デフォルトはoffです。
このパラメータが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のデフォルトは無効です。 その理由は問い合わせ計画がキャッシュされていると間違った結果を返す危険があるからです。 もしテーブル制約が変更もしくは削除されると、その前に生成された計画は間違ったものの可能性がありますが、再計画を強要する組み込まれた機構が存在しません。 （この欠陥は将来のPostgreSQLリリースにおいて取り組まれるかも知れません。） これを無効にしておくその他の理由は、制約検査が比較的高価で、多くの場合に救済をもたらさないからです。 この機能の長所を利用して設計された分割されたテーブルを実際に使用している方のみ、これを有効にすることをお薦めします。
制約による除外およびパーティショニングに関する詳細は項5.9を参照してください。
プランナは、FROMリストがこの数の項目より少ない結果の場合、副問い合わせを上位の問い合わせに併合します。より小さい値は計画時間を縮小させますが、劣った問い合わせ計画をもたらします。デフォルトは8です。通常これをgeqo_threshold以下にしておくと良いでしょう。 詳細は項13.3を参照してください。
最終的にリストがこの項目数以下になる時、プランナは、明示的なJOIN構文（FULL JOINを除く）をFROM項目のリストに直します。 この値を小さくすれば計画作成時間は減少しますが、劣った問い合わせ計画が作成されます。
デフォルトでは、この値はfrom_collapse_limitと同じ値に設定されており、殆どの場合に適切です。 これを1に設定すると明示的なJOINの再順序付けは行われなくなります。 したがって、問い合わせで指定された明示的結合順序は、関係（リレーション）が結合される実際の順序となります。 問い合わせプランナは常に最適な結合順序を選択するとは限りません。 上級ユーザなら暫定的にこの変数を1に設定し、明示的に希望とする結合順序を指定してもよいでしょう。 詳細は項13.3を参照してください。