Enables or disables the query planner's use of async-aware append plan types. The default is <literal>on</literal>. 問い合わせプランナが非同期を意識したアペンド計画型を使うのを可能あるいは不可能にします。 デフォルトはonです。

Enables or disables the query planner's use of bitmap-scan plan types. The default is <literal>on</literal>. 問い合わせプランナがビットマップスキャン計画型を選択することを有効もしくは無効にします。デフォルトはonです。

Enables or disables the query planner's use of gather merge plan types. The default is <literal>on</literal>. 問い合わせプランナがギャザーマージ計画型を選択することを有効もしくは無効にします。 デフォルトはonです。

Enables or disables the query planner's use of hashed aggregation plan types. The default is <literal>on</literal>. 問い合わせプランナがハッシュ集約計画型を選択することを有効もしくは無効にします。 デフォルトはonです。

Enables or disables the query planner's use of hash-join plan types. The default is <literal>on</literal>. 問い合わせプランナがハッシュ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。

Enables or disables the query planner's use of incremental sort steps. The default is <literal>on</literal>. 問い合わせプランナが増分ソートステップを使うのを有効あるいは無効にします。 デフォルトはonです。

Enables or disables the query planner's use of index-scan plan types. The default is <literal>on</literal>. 問い合わせプランナがインデックス走査計画型を選択することを有効もしくは無効にします。デフォルトはonです。

Enables or disables the query planner's use of index-only-scan plan types (see <xref linkend="indexes-index-only-scans"/>). The default is <literal>on</literal>. 問い合わせプランナがインデックスオンリースキャン計画型を選択することを有効もしくは無効にします。 (11.9を参照してください) デフォルトはonです。

Enables or disables the query planner's use of materialization. It is impossible to suppress materialization entirely, but turning this variable off prevents the planner from inserting materialize nodes except in cases where it is required for correctness. The default is <literal>on</literal>. 問い合わせプランナの具体化の使用を有効、または無効にします。 全体にわたって具体化を差し止めることはできませんが、この値をoffにすることにより、正確性が要求される場合を除いて、具体化ノードをプランナが挿入することを防止します。デフォルトはonです。

Enables or disables the query planner's use of memoize plans for caching results from parameterized scans inside nested-loop joins. This plan type allows scans to the underlying plans to be skipped when the results for the current parameters are already in the cache. Less commonly looked up results may be evicted from the cache when more space is required for new entries. The default is <literal>on</literal>. 問い合わせプランナが、ネステッドループ結合の中のパラメータ付き走査の結果をキャッシュするメモ化計画を使用するのを有効あるいは無効にします。 この計画型は、キャッシュ中に現在のパラメータに対応する結果があれば、配下の計画をスキップすることを可能にします。 新しい項目のためにより多くのスペースが必要な場合は、あまり参照されていない結果は削除されるかもしれません。 デフォルトはonです。

Enables or disables the query planner's use of merge-join plan types. The default is <literal>on</literal>. 問い合わせプランナがマージ結合計画型を選択することを有効もしくは無効にします。デフォルトはonです。

Enables or disables the query planner's use of nested-loop join plans. It is impossible to suppress nested-loop joins entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <literal>on</literal>. 問い合わせプランナがネステッドループ結合計画を選択することを有効もしくは無効にします。 ネステッドループ結合を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。 デフォルトはonです。

Enables or disables the query planner's use of parallel-aware append plan types. The default is <literal>on</literal>. 問い合わせプランナによるパラレル認識なアペンド計画型の利用を有効あるいは無効にします。 デフォルトはonです。

Enables or disables the query planner's use of hash-join plan types with parallel hash. Has no effect if hash-join plans are not also enabled. The default is <literal>on</literal>. 問い合わせプランナによる、パラレルハッシュを使ったハッシュジョイン計画型の利用を有効あるいは無効にします。 デフォルトはonです。

Enables or disables the query planner's ability to eliminate a partitioned table's partitions from query plans. This also controls the planner's ability to generate query plans which allow the query executor to remove (ignore) partitions during query execution. The default is <literal>on</literal>. See <xref linkend="ddl-partition-pruning"/> for details. 問い合わせプランナが、クエリプランからパーティション化テーブルのパーティションを除く機能を有効あるいは無効にします。 これはまた、クエリエグゼキュータがクエリ実行中にパーティションを削除（無視）することができるプランを生成するプランナの機能を制御します。 デフォルトはonです。 詳細は5.11.4をご覧ください。

Enables or disables the query planner's use of partitionwise join, which allows a join between partitioned tables to be performed by joining the matching partitions. Partitionwise join currently applies only when the join conditions include all the partition keys, which must be of the same data type and have one-to-one matching sets of child partitions. Because partitionwise join planning can use significantly more CPU time and memory during planning, the default is <literal>off</literal>. パーティション同士の結合(partitionwise join)を問い合わせプランナが使用するのを有効あるいは無効にします。 パーティション同士の結合は、適合するパーティションを結合することによって実行される、パーティション化テーブルにまたがる結合を可能にします。 今の所、パーティション同士の結合は、すべてのパーティションキーを含んでいて、かつパーティションキーの型が同じで、一対一で一致する子パーティションの集合を持つ結合条件のときだけに適用されます。 パーティション同士の結合のプランニングには大量のCPU時間とメモリが使用されることがあるので、デフォルトはoffです。

Enables or disables the query planner's use of partitionwise grouping or aggregation, which allows grouping or aggregation on a partitioned tables performed separately for each partition. If the <literal>GROUP BY</literal> clause does not include the partition keys, only partial aggregation can be performed on a per-partition basis, and finalization must be performed later. Because partitionwise grouping or aggregation can use significantly more CPU time and memory during planning, the default is <literal>off</literal>. パーティション同士（partitionwise）のグループ化、あるいは集約を、問い合わせプランナが使用するのを有効あるいは無効にします。 パーティション同士のグループ化、あるいは集約は、個々のパーティション毎にパーティション化されたテーブルに対して、グループ化あるいは集約を実行するのを可能にします。 GROUP BY句がパーティションキーを含まない場合は、パーティション単位で部分集約だけが実行でき、最終結果の算出は後で行われます。 パーティション同士のグループ化あるいは集約には大量のCPU時間とメモリが使用されることがあるので、デフォルトはoffです。

Controls if the query planner will produce a plan which will provide rows which are presorted in the order required for the query's <literal>ORDER BY</literal> / <literal>DISTINCT</literal> aggregate functions. When disabled, the query planner will produce a plan which will always require the executor to perform a sort before performing aggregation of each aggregate function containing an <literal>ORDER BY</literal> or <literal>DISTINCT</literal> clause. When enabled, the planner will try to produce a more efficient plan which provides input to the aggregate functions which is presorted in the order they require for aggregation. The default value is <literal>on</literal>. 問い合わせプランナが、問い合わせのORDER BY/DISTINCT集約関数に必要なオーダーで事前にソートされた行を生成するかどうかを制御します。 無効の場合、問い合わせプランナは、ORDER BYまたはDISTINCT句を含む各集約関数の集計を実行する前に、ソートをエグゼキュータが実行することを常に要求するプランを生成します。 有効な場合、集約に必要とされる事前にソートされた入力を集約関数に提供する、より効率的なプランをプランナは生成します。 デフォルト値はonです。

Enables or disables the query planner's use of sequential scan plan types. It is impossible to suppress sequential scans entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <literal>on</literal>. 問い合わせプランナがシーケンシャル走査計画型を選択することを有効もしくは無効にします。 シーケンシャル走査を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。 デフォルトはonです。

Enables or disables the query planner's use of explicit sort steps. It is impossible to suppress explicit sorts entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is <literal>on</literal>. 問い合わせプランナが明示的並べ替え手順を選択することを有効もしくは無効にします。 明示的並べ替えを完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。 デフォルトはonです。

Enables or disables the query planner's use of <acronym>TID</acronym> scan plan types. The default is <literal>on</literal>. 問い合わせプランナがTID走査計画型を選択することを有効もしくは無効にします。 デフォルトはonです。

Sets the planner's estimate of the cost of a disk page fetch that is part of a series of sequential fetches. The default is 1.0. This value can be overridden for tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see <xref linkend="sql-altertablespace"/>). シーケンシャルな一連の取り出しの一部となる、ディスクページ取り出しに関する、プランナの推定コストを設定します。 デフォルトは1.0です。 この値は同じ名前のテーブル空間パラメータを設定することで、特定のテーブル空間の中にあるテーブルとインデックスに対して上書きできます（ALTER TABLESPACEを参照してください）。

Sets the planner's estimate of the cost of a non-sequentially-fetched disk page. The default is 4.0. This value can be overridden for tables and indexes in a particular tablespace by setting the tablespace parameter of the same name (see <xref linkend="sql-altertablespace"/>). 非シーケンシャル的に取り出されるディスクページのコストに対するプランナの推測を設定します。 デフォルトは4です。 この値は同じ名前のテーブル空間パラメータを設定することで、特定のテーブル空間の中にあるテーブルとインデックスに対して上書きできます（ALTER TABLESPACEを参照してください）。

Reducing this value relative to <varname>seq_page_cost</varname> will cause the system to prefer index scans; raising it will make index scans look relatively more expensive. You can raise or lower both values together to change the importance of disk I/O costs relative to CPU costs, which are described by the following parameters. この値をseq_page_costと比較して小さくすると、システムはなるべくインデックススキャンを使用するようになります。 大きくすると、インデックススキャンが相対的に高価になります。 両方の値を増減させることで、CPUコストに対するディスクI/Oコストの重要性を変更させることができます。 これについては、後述のパラメータで説明します。

Random access to mechanical disk storage is normally much more expensive than four times sequential access. However, a lower default is used (4.0) because the majority of random accesses to disk, such as indexed reads, are assumed to be in cache. The default value can be thought of as modeling random access as 40 times slower than sequential, while expecting 90% of random reads to be cached. 機械的ディスク記憶装置に対するランダムアクセスは通常はシーケンシャルアクセスの4倍よりもかなり高価です。 しかし、より低いデフォルト（4.0）が使用されます。というのはインデックスのついた読み取りのようなディスクに対するランダムアクセスのほとんどはキャッシュにあると想定されるからです。 このデフォルト値は、ランダムアクセスがシーケンシャルアクセスより40倍遅い一方で、ランダム読み込みの90%はキャッシュされていることが期待されるというモデルとして考えることができます。

If you believe a 90% cache rate is an incorrect assumption for your workload, you can increase random_page_cost to better reflect the true cost of random storage reads. Correspondingly, if your data is likely to be completely in cache, such as when the database is smaller than the total server memory, decreasing random_page_cost can be appropriate. Storage that has a low random read cost relative to sequential, e.g., solid-state drives, might also be better modeled with a lower value for random_page_cost, e.g., <literal>1.1</literal>. 自環境の作業負荷において、90％のキャッシュ率は誤った仮定と考えられるのであれば、ランダム記憶装置読み込みのコストをより良く反映するため random_page_cost を大きくすることができます。 反対に、データが完全にキャッシュされていると思われるのであれば、random_page_cost を小さくすることが適切です。例えば、データベースの容量がサーバのメモリより小さい場合などです。 例えばSSDのような、シーケンシャルアクセスに比べてランダム読み込みコストがあまり大きくない記憶装置の場合も、random_page_cost に対し1.1のようにより低い値のモデル化の方が良いでしょう。

Sets the planner's estimate of the cost of processing each row during a query. The default is 0.01. 問い合わせ時のそれぞれの行の処理コストに対するプランナの推測を設定します。 デフォルトは0.01です。

Sets the planner's estimate of the cost of processing each index entry during an index scan. The default is 0.005. インデックス走査時のそれぞれのインデックス行の処理コストに対するプランナの推測を設定します。 デフォルトは0.005です。

Sets the planner's estimate of the cost of processing each operator or function executed during a query. The default is 0.0025. 問い合わせ時に実行される各演算子や関数の処理コストに対するプランナの推測を設定します。デフォルトは0.0025です。

Sets the planner's estimate of the cost of launching parallel worker processes. The default is 1000. パラレルワーカープロセスを起動するためのコストに対するプランナの推測値を設定します。 デフォルトは1000です。

Sets the planner's estimate of the cost of transferring one tuple from a parallel worker process to another process. The default is 0.1. あるパラレルワーカープロセスから、1行を他のプロセスに転送するためのコストに対するプランナの推測値を設定します。 デフォルトは0.1です。

Sets the minimum amount of table data that must be scanned in order for a parallel scan to be considered. For a parallel sequential scan, the amount of table data scanned is always equal to the size of the table, but when indexes are used the amount of table data scanned will normally be less. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The default is 8 megabytes (<literal>8MB</literal>). パラレルスキャンを考慮する最小のテーブルデータのサイズを指定します。 パラレル順スキャンでは、スキャンされるテーブルのデータ量は、常にテーブルのサイズと同じです。 しかし、インデックスが使われる場合は、スキャンされるテーブルの量は通常少なくなるでしょう。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 デフォルトは8メガバイト（ 8MB）です。

Sets the minimum amount of index data that must be scanned in order for a parallel scan to be considered. Note that a parallel index scan typically won't touch the entire index; it is the number of pages which the planner believes will actually be touched by the scan which is relevant. This parameter is also used to decide whether a particular index can participate in a parallel vacuum. See <xref linkend="sql-vacuum"/>. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The default is 512 kilobytes (<literal>512kB</literal>). パラレルスキャンが考慮されるために、スキャンされなければならないインデックスデータの最小量を設定します。 通常パラレルインデックススキャンは、典型的にはインデックス全体をアクセスしないことに注意してください。 これは、関連するスキャンにより、プランナが実際にアクセスされると信じるページ数です。 またこのパラメータは、あるインデックスがパラレルVACUUMで利用できるかどうかを決定するのにも使われます。 VACUUMをご覧ください。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 デフォルトは512キロバイト（512kB）です。

Sets the planner's assumption about the effective size of the disk cache that is available to a single query. This is factored into estimates of the cost of using an index; a higher value makes it more likely index scans will be used, a lower value makes it more likely sequential scans will be used. When setting this parameter you should consider both <productname>PostgreSQL</productname>'s shared buffers and the portion of the kernel's disk cache that will be used for <productname>PostgreSQL</productname> data files, though some data might exist in both places. Also, take into account the expected number of concurrent queries on different tables, since they will have to share the available space. This parameter has no effect on the size of shared memory allocated by <productname>PostgreSQL</productname>, nor does it reserve kernel disk cache; it is used only for estimation purposes. The system also does not assume data remains in the disk cache between queries. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The default is 4 gigabytes (<literal>4GB</literal>). (If <symbol>BLCKSZ</symbol> is not 8kB, the default value scales proportionally to it.) 単一の問い合わせで利用できるディスクキャッシュの実効容量に関するプランナの条件を設定します。 これは、インデックスを使用するコスト推定値の要素となります。 より高い値にすれば、よりインデックススキャンが使用されるようになり、より小さく設定すれば、シーケンシャルスキャンがより使用されるようになります。 このパラメータを設定する時には、PostgreSQLの共有バッファとPostgreSQLデータファイルに使用されるカーネルのディスクキャッシュの量の両方を考慮しなければなりませんが、データは両方に存在することもあります。 また、利用可能な領域を共有しますので、異なるテーブルに対して同時に実行される問い合わせの想定数も考慮してください。 このパラメータは、PostgreSQLで割り当てられる共有メモリの大きさには影響を与えません。また、カーネルのディスクキャッシュを予約したりもしません。 これは推定目的のみで使用されます。 同時に、システムは問い合わせの間のディスクキャッシュ内のデータの残滓を想定していません。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 デフォルトは4ギガバイト（4GB）です。 (BLCKSZが8kbでなければ、この設定のデフォルト値と最大値がBLCKSZに比例して変更されます。)

Sets the query cost above which JIT compilation is activated, if enabled (see <xref linkend="jit"/>). Performing <acronym>JIT</acronym> costs planning time but can accelerate query execution. Setting this to <literal>-1</literal> disables JIT compilation. The default is <literal>100000</literal>. JITが有効な場合（第32章参照）、それ以上ならJITコンパイルが起動する問い合わせコストを設定します。 JITを実行するとプラン時間がかかりますが、問い合わせの実行を高速化することができます。 これを-1にすると、JITコンパイルは無効になります。 デフォルトは100000です。

Sets the query cost above which JIT compilation attempts to inline functions and operators. Inlining adds planning time, but can improve execution speed. It is not meaningful to set this to less than <varname>jit_above_cost</varname>. Setting this to <literal>-1</literal> disables inlining. The default is <literal>500000</literal>. それ以上ならJITコンパイルが関数と演算子のインライン化を試みる問い合わせコストを設定します。 インライン化するとプラン時間がかかりますが、問い合わせの実行速度を改善できます。 これをjit_above_costよりも小さくするのは意味がありません。 これを-1にすると、インライン化は無効になります。 デフォルトは500000です。

Sets the query cost above which JIT compilation applies expensive optimizations. Such optimization adds planning time, but can improve execution speed. It is not meaningful to set this to less than <varname>jit_above_cost</varname>, and it is unlikely to be beneficial to set it to more than <varname>jit_inline_above_cost</varname>. Setting this to <literal>-1</literal> disables expensive optimizations. The default is <literal>500000</literal>. それ以上ならJITコンパイルが高価な最適化を実行する問い合わせコストを設定します。 そうした最適化にはプラン時間がかかりますが、問い合わせの実行速度を改善できます。 これをjit_above_costよりも小さくするのは意味がなく、またjit_inline_above_costよりも大きくしても利益はないでしょう。 これを-1にすると、高価な最適化は無効になります デフォルトは500000です。

Enables or disables genetic query optimization. This is on by default. It is usually best not to turn it off in production; the <varname>geqo_threshold</varname> variable provides more granular control of GEQO. 遺伝的問い合わせ最適化を有効もしくは無効にします。デフォルトは有効です。 運用時には無効にしないことが通常最善です。geqo_threshold変数は、GEQOを制御するためよりきめ細かな方法を提供します。

Use genetic query optimization to plan queries with at least this many <literal>FROM</literal> items involved. (Note that a <literal>FULL OUTER JOIN</literal> construct counts as only one <literal>FROM</literal> item.) The default is 12. For simpler queries it is usually best to use the regular, exhaustive-search planner, but for queries with many tables the exhaustive search takes too long, often longer than the penalty of executing a suboptimal plan. Thus, a threshold on the size of the query is a convenient way to manage use of GEQO. 少なくともこれだけの数のFROM項目数があるときに、問い合わせを計画するのに遺伝的問い合わせ最適化を使用します。 （FULL OUTER JOINの生成子は、FROM項目が１つだけとして計算することに注意してください。） デフォルトは12です。 もっと単純な問い合わせでは、通常の、そしてしらみつぶしの検索プランナを使用するのが最善ですが、多くのテーブルを持つ問い合わせでは、しらみつぶしの検索は非常に時間がかかり、しばしば次善の計画を実行する代償より長くなります。 従って、問い合わせの大きさに対する閾値はGEQOの使用を管理するのに便利な方法です。

Controls the trade-off between planning time and query plan quality in GEQO. This variable must be an integer in the range from 1 to 10. The default value is five. Larger values increase the time spent doing query planning, but also increase the likelihood that an efficient query plan will be chosen. GEQOにおける計画時間と問い合わせ計画の品質間のトレードオフを制御します。この変数は1から10までの範囲の整数でなければなりません。 デフォルトの値は5です。値を大きくすると、問い合わせ計画作成により多くの時間を費すことになりますが、より効率的な問い合わせ計画が選択される可能性が増加します。

<varname>geqo_effort</varname> doesn't actually do anything directly; it is only used to compute the default values for the other variables that influence GEQO behavior (described below). If you prefer, you can set the other parameters by hand instead. 実際geqo_effortは直接何も行いません。それはGEQOの動作に影響を与える他の変数に対し、デフォルトの値を計算するためにのみ使用されます（以下で説明します）。もしよければ、代わりに手作業で他のパラメータを設定できます。

Controls the pool size used by GEQO, that is the number of individuals in the genetic population. It must be at least two, and useful values are typically 100 to 1000. If it is set to zero (the default setting) then a suitable value is chosen based on <varname>geqo_effort</varname> and the number of tables in the query. GEQOで使用されるプール容量を管理します。それは遺伝的個体群内の個体数です。最低でも2つはなければならず、よく100から1000までの値が使用されます。 もし（デフォルトの設定である）零に設定されると、geqo_effortおよび問い合わせの中のテーブル数に基づいて、適切な値が選択されます。

Controls the number of generations used by GEQO, that is the number of iterations of the algorithm. It must be at least one, and useful values are in the same range as the pool size. If it is set to zero (the default setting) then a suitable value is chosen based on <varname>geqo_pool_size</varname>. GEQOで使用される世代の数を管理します。それはアルゴリズムの反復数です。最低でも1はなければならず、よくプールサイズと同じ範囲の値が使用されます。 これを0に設定（デフォルトの設定）すると、適切な値がgeqo_pool_sizeに基づいて選択されます。

Controls the selection bias used by GEQO. The selection bias is the selective pressure within the population. Values can be from 1.50 to 2.00; the latter is the default. GEQOで使用される淘汰の偏りを管理します。 淘汰の偏りは個体群内の（遺伝的な）自然淘汰です。値は1.50から2.00で、2.00がデフォルトです。

Controls the initial value of the random number generator used by GEQO to select random paths through the join order search space. The value can range from zero (the default) to one. Varying the value changes the set of join paths explored, and may result in a better or worse best path being found. 結合順序検索空間にわたって、GEQOが無作為のパスを選択するために使用される乱数発生器の初期値を制御します。 値は0（デフォルト）から1までの範囲です。 値を変動させると探査される結合パスの集合が変化するため、見つかる最善のパスが良くなる場合も悪くなる場合もあります。

Sets the default statistics target for table columns without a column-specific target set via <command>ALTER TABLE SET STATISTICS</command>. Larger values increase the time needed to do <command>ANALYZE</command>, but might improve the quality of the planner's estimates. The default is 100. For more information on the use of statistics by the <productname>PostgreSQL</productname> query planner, refer to <xref linkend="planner-stats"/>. ALTER TABLE SET STATISTICSで列特定の目的セットの無いテーブル列に対し、デフォルトの統計対象を設定します。 より大きい値はANALYZEに必要な時間を増加させますが、プランナの予測の品質を向上させます。 デフォルトは100です。 PostgreSQLの問い合わせプランナによる統計情報の使用方法に関するより詳細な情報は、14.2を参照してください。

Controls the query planner's use of table constraints to optimize queries. The allowed values of <varname>constraint_exclusion</varname> are <literal>on</literal> (examine constraints for all tables), <literal>off</literal> (never examine constraints), and <literal>partition</literal> (examine constraints only for inheritance child tables and <literal>UNION ALL</literal> subqueries). <literal>partition</literal> is the default setting. It is often used with traditional inheritance trees to improve performance. 問い合わせプランナが問い合わせを最適化する際のテーブル制約の使用を制御します。 constraint_exclusionに許容される値は、on（全てのテーブルに対し制約を検査する）、off（決して制約を検査しない）、およびpartition（継承された子テーブルおよびUNION ALL副問い合わせのみ制約を検査する）です。 partitionがデフォルトの設定です。 伝統的な継承ツリーでしばしば性能向上のために使用されます。

When this parameter allows it for a particular table, the planner compares query conditions with the table's <literal>CHECK</literal> constraints, and omits scanning tables for which the conditions contradict the constraints. For example: このパラメータが特定のテーブルに対して許される時、プランナはそのテーブルの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;

With constraint exclusion enabled, this <command>SELECT</command> will not scan <structname>child1000</structname> at all, improving performance. 制約排除が有効であると、このSELECTは全くchild1000を走査せず、性能を向上させます。

Currently, constraint exclusion is enabled by default only for cases that are often used to implement table partitioning via inheritance trees. Turning it on for all tables imposes extra planning overhead that is quite noticeable on simple queries, and most often will yield no benefit for simple queries. If you have no tables that are partitioned using traditional inheritance, you might prefer to turn it off entirely. (Note that the equivalent feature for partitioned tables is controlled by a separate parameter, <xref linkend="guc-enable-partition-pruning"/>.) 現在、継承ツリーを使ってテーブルパーティショニングを実装するために使用されるよくある場合のことだけを考慮して、制約排除はデフォルトで有効です。 すべてのテーブルに対して有効にするのは、単純な問い合わせにおいて特にはっきりわかる計画作成の余計なオーバーヘッドをもたらし、単純な問い合わせにはメリットがありません。 伝統的な継承を使うパーティショニングされたテーブルがない場合、完全に無効にする方が良いでしょう。 （パーティショニングされたテーブル用の同等の機能は別のパラメータenable_partition_pruningで制御します。）

Refer to <xref linkend="ddl-partitioning-constraint-exclusion"/> for more information on using constraint exclusion to implement partitioning. パーティショニングを実装するための制約排除の利用についてのより進んだ情報は5.11.5を参照ください。

Sets the planner's estimate of the fraction of a cursor's rows that will be retrieved. The default is 0.1. Smaller values of this setting bias the planner towards using <quote>fast start</quote> plans for cursors, which will retrieve the first few rows quickly while perhaps taking a long time to fetch all rows. Larger values put more emphasis on the total estimated time. At the maximum setting of 1.0, cursors are planned exactly like regular queries, considering only the total estimated time and not how soon the first rows might be delivered. 検索されるカーソル行の割合のプランナの見積もりを設定します。 デフォルトは0.1です。 この設定をより小さくすると、プランナはカーソルに対し「起動を高速にする」計画を使用するようになりがちになります。 この場合先頭の数行の取り出しは高速になりますが、行全体を取り出す場合に時間がかかるようになる可能性があります。 この値をより大きくすると、推定時間全体がより強調されるようになります。 最大の設定である1.0の場合、カーソルは通常の問い合わせとまったく同様に計画されます。 つまり、推定時間全体のみが考慮され、先頭の行の取り出しにかかる時間は考慮されなくなります。

The planner will merge sub-queries into upper queries if the resulting <literal>FROM</literal> list would have no more than this many items. Smaller values reduce planning time but might yield inferior query plans. The default is eight. For more information see <xref linkend="explicit-joins"/>. プランナは、FROMリストがこの数の項目より少ない結果の場合、副問い合わせを上位の問い合わせに併合します。 より小さい値は計画時間を縮小させますが、劣った問い合わせ計画をもたらす可能性があります。 デフォルトは8です。 詳細は14.3を参照してください。

Setting this value to <xref linkend="guc-geqo-threshold"/> or more may trigger use of the GEQO planner, resulting in non-optimal plans. See <xref linkend="runtime-config-query-geqo"/>. この値をgeqo_thresholdか、それ以上に設定するとGEQOプランナ使用の誘引となり、最適ではない計画をもたらします。20.7.3を参照してください。

Determines whether <acronym>JIT</acronym> compilation may be used by <productname>PostgreSQL</productname>, if available (see <xref linkend="jit"/>). The default is <literal>on</literal>. PostgreSQLが、可能ならばJITコンパイルを使うかどうかを決定します（第32章を参照）。 デフォルトはonです。

The planner will rewrite explicit <literal>JOIN</literal> constructs (except <literal>FULL JOIN</literal>s) into lists of <literal>FROM</literal> items whenever a list of no more than this many items would result. Smaller values reduce planning time but might yield inferior query plans. 最終的にリストがこの項目数以下になる時、プランナは、明示的なJOIN構文（FULL JOINを除く）をFROM項目のリストに直します。 この値を小さくすれば計画作成時間は減少しますが、劣った問い合わせ計画が作成される可能性があります。

By default, this variable is set the same as <varname>from_collapse_limit</varname>, which is appropriate for most uses. Setting it to 1 prevents any reordering of explicit <literal>JOIN</literal>s. Thus, the explicit join order specified in the query will be the actual order in which the relations are joined. Because the query planner does not always choose the optimal join order, advanced users can elect to temporarily set this variable to 1, and then specify the join order they desire explicitly. For more information see <xref linkend="explicit-joins"/>. デフォルトでは、この値はfrom_collapse_limitと同じ値に設定されており、殆どの場合に適切です。 これを1に設定すると明示的なJOINの再順序付けは行われなくなります。 したがって、問い合わせで指定された明示的結合順序は、関係（リレーション）が結合される実際の順序となります。 問い合わせプランナは常に最適な結合順序を選択するとは限らないので、 上級ユーザなら暫定的にこの変数を1に設定し、明示的に希望とする結合順序を指定してもよいでしょう。 詳細は14.3を参照してください。

Setting this value to <xref linkend="guc-geqo-threshold"/> or more may trigger use of the GEQO planner, resulting in non-optimal plans. See <xref linkend="runtime-config-query-geqo"/>. この値をgeqo_thresholdか、それ以上に設定するとGEQOプランナ使用の誘引となり、最適ではない計画をもたらします。20.7.3を参照してください。

Prepared statements (either explicitly prepared or implicitly generated, for example by PL/pgSQL) can be executed using custom or generic plans. Custom plans are made afresh for each execution using its specific set of parameter values, while generic plans do not rely on the parameter values and can be re-used across executions. Thus, use of a generic plan saves planning time, but if the ideal plan depends strongly on the parameter values then a generic plan may be inefficient. The choice between these options is normally made automatically, but it can be overridden with <varname>plan_cache_mode</varname>. The allowed values are <literal>auto</literal> (the default), <literal>force_custom_plan</literal> and <literal>force_generic_plan</literal>. This setting is considered when a cached plan is to be executed, not when it is prepared. For more information see <xref linkend="sql-prepare"/>. 準備された文（明示的に準備されたものあるいはPL/pgSQLのように暗黙的に生成されたもののどちらにおいても）は、カスタムあるいは汎用(generic)プランで実行することができます。 カスタムプランは実行ごとに指定されたパラメータ値の集合で新たに作られます。 一方汎用プランはパラメータ値に依存せず、複数の実行にまたがって再利用できます。 したがって、汎用プランはプランニングに要する時間を節約できますが、理想的なプランがパラメータ値に強く依存している場合は、汎用プランは非効率かも知れません。 通常この両者の選択は自動的に行われますが、plan_cache_modeで上書きできます。 可能な値はauto（デフォルト）、force_custom_plan、force_generic_planです。 この設定は、準備するときではなく、キャッシュされたプランを実行する際に考慮されます。 詳細はPREPAREをご覧ください。

Sets the planner's estimate of the average size of the working table of a <link linkend="queries-with-recursive">recursive query</link>, as a multiple of the estimated size of the initial non-recursive term of the query. This helps the planner choose the most appropriate method for joining the working table to the query's other tables. The default value is <literal>10.0</literal>. A smaller value such as <literal>1.0</literal> can be helpful when the recursion has low <quote>fan-out</quote> from one step to the next, as for example in shortest-path queries. Graph analytics queries may benefit from larger-than-default values. 再帰問合せのワーキング・テーブルの平均サイズのプランナの推定値を、問合せの最初の非再帰項の推定サイズの倍数として設定します。 これにより、プランナは、ワーキング・テーブルを問合せの他のテーブルに結合するための最も適切な方法を選択できます。 デフォルト値は10.0です。 1.0などの小さい値は、最短パス問合せなど、あるステップから次のステップへの再帰が低い「広がり方(fanout)」の場合に役立ちます。 グラフ分析の問合せでは、デフォルト値より大きい値が有効な場合があります。