These configuration parameters provide a crude method of
influencing the query plans chosen by the query optimizer. If
the default plan chosen by the optimizer for a particular query
is not optimal, a <emphasis>temporary</emphasis> solution is to use one
of these configuration parameters to force the optimizer to
choose a different plan.
Better ways to improve the quality of the
plans chosen by the optimizer include adjusting the planner cost
constants (see <xref linkend="runtime-config-query-constants"/>),
running <link linkend="sql-analyze"><command>ANALYZE</command></link> manually, increasing
the value of the <xref
linkend="guc-default-statistics-target"/> configuration parameter,
and increasing the amount of statistics collected for
specific columns using <command>ALTER TABLE SET
STATISTICS</command>.
以下の設定パラメータは、問い合わせオプティマイザが選択する問い合わせ計画に影響する大雑把な手法を提供します。
ある問い合わせに対してオプティマイザが選択したデフォルト計画が最適でない場合、暫定的な解決策は、これらの設定パラメータの1つを使用し、オプティマイザに異なる計画を選択するように仕向けることです。
オプティマイザが選択する計画の品質を改善するためのより良い方法には、プランナコスト定数を調節する(19.7.2を参照)、ANALYZE
を手作業で実行する、default_statistics_target設定パラメータの値を大きくする、ALTER TABLE SET STATISTICS
を使用して、特定の列に対して収集される統計情報を増やす、などがあります。
enable_async_append
(boolean
)
#
Enables or disables the query planner's use of async-aware
append plan types. The default is <literal>on</literal>.
問い合わせプランナが非同期を意識したアペンド計画型を使うのを可能あるいは不可能にします。
デフォルトはon
です。
enable_bitmapscan
(boolean
)
#
Enables or disables the query planner's use of bitmap-scan plan
types. The default is <literal>on</literal>.
問い合わせプランナがビットマップスキャン計画型を選択することを有効もしくは無効にします。デフォルトはon
です。
enable_gathermerge
(boolean
)
#
Enables or disables the query planner's use of gather
merge plan types. The default is <literal>on</literal>.
問い合わせプランナがギャザーマージ計画型を選択することを有効もしくは無効にします。
デフォルトはon
です。
enable_group_by_reordering
(boolean
)
#
Controls if the query planner will produce a plan which will provide
<literal>GROUP BY</literal> keys sorted in the order of keys of
a child node of the plan, such as an index scan. When disabled, the
query planner will produce a plan with <literal>GROUP BY</literal>
keys only sorted to match the <literal>ORDER BY</literal> clause,
if any. When enabled, the planner will try to produce a more
efficient plan. The default value is <literal>on</literal>.
問い合わせプランナが、インデックススキャンのようなプランの子ノードのキーの順でソートされたGROUP BY
キーを提供するプランを生成するかどうかを制御します。
無効にすると、問い合わせプランナは、GROUP BY
句があれば、それに合わせたソート順のORDER BY
キーを持つプランを生成します。
有効にすると、プランナはより効率的プランの生成を試みます。
デフォルト値はon
です。
enable_hashagg
(boolean
)
#
Enables or disables the query planner's use of hashed
aggregation plan types. The default is <literal>on</literal>.
問い合わせプランナがハッシュ集約計画型を選択することを有効もしくは無効にします。
デフォルトはon
です。
enable_hashjoin
(boolean
)
#
Enables or disables the query planner's use of hash-join plan
types. The default is <literal>on</literal>.
問い合わせプランナがハッシュ結合計画型を選択することを有効もしくは無効にします。デフォルトはon
です。
enable_incremental_sort
(boolean
)
#
Enables or disables the query planner's use of incremental sort steps.
The default is <literal>on</literal>.
問い合わせプランナが増分ソートステップを使うのを有効あるいは無効にします。
デフォルトはon
です。
enable_indexscan
(boolean
)
#
Enables or disables the query planner's use of index-scan plan
types. The default is <literal>on</literal>.
問い合わせプランナがインデックス走査計画型を選択することを有効もしくは無効にします。デフォルトはon
です。
enable_indexonlyscan
(boolean
)
#
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
です。
enable_material
(boolean
)
#
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
です。
enable_memoize
(boolean
)
#
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
です。
enable_mergejoin
(boolean
)
#
Enables or disables the query planner's use of merge-join plan
types. The default is <literal>on</literal>.
問い合わせプランナがマージ結合計画型を選択することを有効もしくは無効にします。デフォルトはon
です。
enable_nestloop
(boolean
)
#
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
です。
enable_parallel_append
(boolean
)
#
Enables or disables the query planner's use of parallel-aware
append plan types. The default is <literal>on</literal>.
問い合わせプランナによるパラレル認識なアペンド計画型の利用を有効あるいは無効にします。
デフォルトはon
です。
enable_parallel_hash
(boolean
)
#
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
です。
enable_partition_pruning
(boolean
)
#
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.12.4をご覧ください。
enable_partitionwise_join
(boolean
)
#
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. With this setting enabled, the number of nodes
whose memory usage is restricted by <varname>work_mem</varname>
appearing in the final plan can increase linearly according to the
number of partitions being scanned. This can result in a large
increase in overall memory consumption during the execution of the
query. Query planning also becomes significantly more expensive in
terms of memory and CPU. The default value is <literal>off</literal>.
パーティション同士の結合(partitionwise join)を問い合わせプランナが使用するのを有効あるいは無効にします。
パーティション同士の結合は、適合するパーティションを結合することによって実行される、パーティション化テーブルにまたがる結合を可能にします。
今の所、パーティション同士の結合は、すべてのパーティションキーを含んでいて、かつパーティションキーの型が同じで、一対一で一致する子パーティションの集合を持つ結合条件のときだけに適用されます。
この設定を有効にすると、最終プランに表示され、work_mem
によってメモリ使用が制限されるノードの数は、スキャンされるパーティションの数に応じて直線的に増加します。
これにより、問い合わせの実行中の全体的なメモリ消費の大きな増加をもたらす可能性があります。
また、問い合わせ計画の作成が、メモリとCPU使用率の点でも非常に高価になります。
デフォルト値はoff
です。
enable_partitionwise_aggregate
(boolean
)
#
Enables or disables the query planner's use of partitionwise grouping
or aggregation, which allows grouping or aggregation on partitioned
tables to be 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. With this setting
enabled, the number of nodes whose memory usage is restricted by
<varname>work_mem</varname> appearing in the final plan can increase
linearly according to the number of partitions being scanned. This
can result in a large increase in overall memory consumption during
the execution of the query. Query planning also becomes significantly
more expensive in terms of memory and CPU. The default value is
<literal>off</literal>.
パーティション化されたテーブルに対してグループ化または集約を個別に実行できるように、問い合わせプランナのパーティションごと(partitionwise)のグループ化または集約の使用を有効または無効にします。
GROUP BY
句がパーティションキーを含まない場合は、パーティション単位で部分集約だけが実行でき、最終結果の算出は後で行われます。
この設定を有効にすると、最終プランに表示され、work_mem
によってメモリ使用が制限されるノードの数は、スキャンされるパーティションの数に応じて直線的に増加します。
これにより、問い合わせの実行中の全体的なメモリ消費の大きな増加をもたらす可能性があります。
また、問い合わせ計画の作成が、メモリとCPU使用率の点でも非常に高価になります。
デフォルト値はoff
です。
enable_presorted_aggregate
(boolean
)
#
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
です。
enable_seqscan
(boolean
)
#
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
です。
enable_sort
(boolean
)
#
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
です。
enable_tidscan
(boolean
)
#
Enables or disables the query planner's use of <acronym>TID</acronym>
scan plan types. The default is <literal>on</literal>.
問い合わせプランナがTID走査計画型を選択することを有効もしくは無効にします。
デフォルトはon
です。
The <firstterm>cost</firstterm> variables described in this section are measured
on an arbitrary scale. Only their relative values matter, hence
scaling them all up or down by the same factor will result in no change
in the planner's choices. By default, these cost variables are based on
the cost of sequential page fetches; that is,
<varname>seq_page_cost</varname> is conventionally set to <literal>1.0</literal>
and the other cost variables are set with reference to that. But
you can use a different scale if you prefer, such as actual execution
times in milliseconds on a particular machine.
本節で扱うコスト変数は、任意の尺度で測られます。
これらは相対的な値のみが意味を持つため、それらの値をすべて同じ係数で大きく、あるいは小さくしても、プランナの選択は結果として変わりません。
デフォルトではこれらのコスト変数はシーケンシャルなページ取り込みに基づいています。
つまり、seq_page_cost
を慣習的に1.0
とし、他のコスト変数はそれを参考にして設定されています。
しかし望むなら、特定のマシンにおけるミリ秒単位の実行時間など、異なる尺度を使用することができます。
Unfortunately, there is no well-defined method for determining ideal values for the cost variables. They are best treated as averages over the entire mix of queries that a particular installation will receive. This means that changing them on the basis of just a few experiments is very risky. 残念ながら、コスト変数に対する理想的な値を決定する、上手く定義された方法がありません。 特定のインストレーションが受け取る問い合わせ全体を混在させたものの平均として扱うのが最善でしょう。 数回の実験のみを根拠にこの値を変更することは危険であるといえます。
seq_page_cost
(floating point
)
#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を参照してください)。
random_page_cost
(floating point
)
#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
のようにより低い値のモデル化の方が良いでしょう。
Although the system will let you set <varname>random_page_cost</varname> to
less than <varname>seq_page_cost</varname>, it is not physically sensible
to do so. However, setting them equal makes sense if the database
is entirely cached in RAM, since in that case there is no penalty
for touching pages out of sequence. Also, in a heavily-cached
database you should lower both values relative to the CPU parameters,
since the cost of fetching a page already in RAM is much smaller
than it would normally be.
システムはrandom_page_cost
をseq_page_cost
よりも小さな値に設定することを許しますが、そのようにすることは物理的にはおかしなことです。
しかし、データベースが完全にRAMにキャッシュされる場合、同じ値に設定することは意味を持ちます。
この場合、順序通りではないページアクセスに対するペナルティが存在しないからです。
また、多くがキャッシュされるデータベースでは、CPUパラメータに対して両値を小さく設定すべきです。
RAM内に存在するページの取り出しコストは通常よりもかなり小さくなるためです。
cpu_tuple_cost
(floating point
)
#Sets the planner's estimate of the cost of processing each row during a query. The default is 0.01. 問い合わせ時のそれぞれの行の処理コストに対するプランナの推測を設定します。 デフォルトは0.01です。
cpu_index_tuple_cost
(floating point
)
#Sets the planner's estimate of the cost of processing each index entry during an index scan. The default is 0.005. インデックス走査時のそれぞれのインデックス行の処理コストに対するプランナの推測を設定します。 デフォルトは0.005です。
cpu_operator_cost
(floating point
)
#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です。
parallel_setup_cost
(floating point
)
#Sets the planner's estimate of the cost of launching parallel worker processes. The default is 1000. パラレルワーカープロセスを起動するためのコストに対するプランナの推測値を設定します。 デフォルトは1000です。
parallel_tuple_cost
(floating point
)
#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です。
min_parallel_table_scan_size
(integer
)
#
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
)です。
min_parallel_index_scan_size
(integer
)
#
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
)です。
effective_cache_size
(integer
)
#
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
に比例して変更されます。)
jit_above_cost
(floating point
)
#
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が有効な場合(第30章参照)、それ以上ならJITコンパイルが起動する問い合わせコストを設定します。
JITを実行するとプラン時間がかかりますが、問い合わせの実行を高速化することができます。
これを-1
にすると、JITコンパイルは無効になります。
デフォルトは100000
です。
jit_inline_above_cost
(floating point
)
#
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
です。
jit_optimize_above_cost
(floating point
)
#
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
です。
The genetic query optimizer (GEQO) is an algorithm that does query planning using heuristic searching. This reduces planning time for complex queries (those joining many relations), at the cost of producing plans that are sometimes inferior to those found by the normal exhaustive-search algorithm. For more information see <xref linkend="geqo"/>. 遺伝的問い合わせオプティマイザ(GEQO)はヒューリスティック(発見的)検索法を用いた問い合わせ計画を行なう演算手法です。 通常のしらみつぶしの検索演算手法で見いだされる計画よりも時として劣った計画を作成するという代償を払いますが、この手法は(多くのリレーションを結合するような)複雑な問い合わせに対し計画時間を軽減します。 より詳細は第60章を参照してください。
geqo
(boolean
)
#
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を制御するためよりきめ細かな方法を提供します。
geqo_threshold
(integer
)
#
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
項目が1つだけとして計算することに注意してください。)
デフォルトは12です。
もっと単純な問い合わせでは、通常の、そしてしらみつぶしの検索プランナを使用するのが最善ですが、多くのテーブルを持つ問い合わせでは、しらみつぶしの検索は非常に時間がかかり、しばしば次善の計画を実行する代償より長くなります。
従って、問い合わせの大きさに対する閾値はGEQOの使用を管理するのに便利な方法です。
geqo_effort
(integer
)
#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の動作に影響を与える他の変数に対し、デフォルトの値を計算するためにのみ使用されます(以下で説明します)。もしよければ、代わりに手作業で他のパラメータを設定できます。
geqo_pool_size
(integer
)
#
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
および問い合わせの中のテーブル数に基づいて、適切な値が選択されます。
geqo_generations
(integer
)
#
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
に基づいて選択されます。
geqo_selection_bias
(floating point
)
#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がデフォルトです。
geqo_seed
(floating point
)
#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までの範囲です。 値を変動させると探査される結合パスの集合が変化するため、見つかる最善のパスが良くなる場合も悪くなる場合もあります。
default_statistics_target
(integer
)
#
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を参照してください。
constraint_exclusion
(enum
)
#
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.12.5を参照ください。
cursor_tuple_fraction
(floating point
)
#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の場合、カーソルは通常の問い合わせとまったく同様に計画されます。 つまり、推定時間全体のみが考慮され、先頭の行の取り出しにかかる時間は考慮されなくなります。
from_collapse_limit
(integer
)
#
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プランナ使用の誘引となり、最適ではない計画をもたらします。19.7.3を参照してください。
jit
(boolean
)
#
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コンパイルを使うかどうかを決定します(第30章を参照)。
デフォルトはon
です。
join_collapse_limit
(integer
)
#
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プランナ使用の誘引となり、最適ではない計画をもたらします。19.7.3を参照してください。
plan_cache_mode
(enum
)
#
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をご覧ください。
recursive_worktable_factor
(floating point
)
#
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)」の場合に役立ちます。
グラフ分析の問合せでは、デフォルト値より大きい値が有効な場合があります。