問い合わせ計画

PostgreSQL 8.4.1文書
前のページ | 巻戻し | 第 18章サーバの構成 | 早送り | 次のページ

# 18.6. 問い合わせ計画

## 18.6.1. プランナ方針構成

これらの設定パラメータは、問い合わせオプティマイザが選択する問い合わせ計画に影響する大雑把な手法を提供します。 もしも、ある問い合わせに対してオプティマイザが選択したデフォルト計画が最適でない場合、暫定的な解決策は、これらの設定パラメータの1つを使用し、オプティマイザに異なる計画を選択するように仕向けることです。 とは言っても、永久にこれらの設定を無効にすることはあまり勧められません。 品質を改良する方策は、次のようにしてオプティマイザが選択する計画の品質を向上することです。 プランナコスト定数を調節し、ANALYZEをより頻繁に実行し、default_statistics_target設定パラメータの値を大きくし、そして`ALTER TABLE SET STATISTICS`を使用して、特定の列に対して収集された統計情報を増やします。

`enable_bitmapscan`（`論理値`）

  問い合わせプランナがビットマップ走計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

`enable_hashagg`（`論理値`）

  問い合わせプランナがハッシュされた集約計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

`enable_hashjoin`（`論理値`）

  問い合わせプランナがハッシュ結合計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

`enable_indexscan`（`論理値`）

  問い合わせプランナがインデックス走査計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

`enable_mergejoin`（`論理値`）

  問い合わせプランナがマージ結合計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

`enable_nestloop`（`論理値`

  問い合わせプランナが入れ子になったループ結合計画を選択することを有効もしくは無効にします。入れ子ループ結合を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトは`on`です。

`enable_seqscan`（`論理値`）

  問い合わせプランナがシーケンシャル査計画を選択することを有効もしくは無効にします。シーケンシャル走査を完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトは`on`です。

`enable_sort`（`論理値`）

  問い合わせプランナが明示的並び替え手順を選択することを有効もしくは無効にします。明示的並び替えを完全に禁止することは不可能ですが、この変数をオフにすると、もし他の方法が利用できるのであれば、プランナはその使用を行わないようになります。デフォルトは`on`です。

`enable_tidscan`（`論理値`）

  問い合わせプランナがTID走査計画型を選択することを有効もしくは無効にします。デフォルトは`on`です。

## 18.6.2. プランナコスト定数

本節で扱うコスト変数は、任意の尺度で測られます。 これらは相対的な値でしかありません。 そのため、同じ因子で尺度を変えても、プランナの選択は結果として変わりません。 伝統的に、これらの変数はコスト単位としてシーケンシャルなページ取り込みを参照していました。 つまり、`seq_page_cost`を慣習的に`1.0`とし、他のコスト変数をそれを参考にして設定されていました。 しかし望むなら、特定のマシンにおけるミリ秒単位の実行時間など、異なる尺度を使用することができます。

> 注意: 残念ながら、コスト変数に対する理想的な値を決定する、上手く定義された方法がありません。 特定のインストレーションが行うだろう問い合わせ全体を混在させたものの平均を最善のものとして扱われています。 数回の実験のみを根拠にこの値を変更することは危険であるといえます。

`seq_page_cost` (`浮動少数点`)

  シーケンシャルな一連の取り出しの一部となる、ディスクページ取り出しに関する、プランナの推定コストを設定します。 デフォルトは1.0です。

`random_page_cost`（`浮動小数点`）

  非シーケンシャルに取り出されるディスクページのコストに対するプランナの推測を設定します。 デフォルトは4です。 この値を`seq_page_cost`に相対的に減少させると、システムはインデックススキャンを好んで使用するようになります。 増加させると、インデックススキャンが相対的に高価になります。 両方の値を増減させることで、CPUコストに対するディスクI/Oの重要性を変更させることができます。 これについては、後述のパラメータで説明します。

  > ティップ: システムは`random_page_cost`を`seq_page_cost`よりも小さな値に設定しようとしますが、これには物理的な意味はありません。 しかし、データベースが完全にRAMにキャッシュされる場合、同じ値に設定することは意味を持ちます。 この場合、順序通りではないページアクセスに対するペナルティが存在しないからです。 また、多くがキャッシュされるデータベースでは、CPUパラメータに対して両値を小さく設定すべきです。 RAM内に存在するページの取り出しコストは通常よりもかなり小さくなるためです。

`cpu_tuple_cost`（`浮動小数点`）

  問い合わせ間にそれぞれの行の処理に対するプランナの推測を設定します。デフォルトは0.01です。

`cpu_index_tuple_cost`（`浮動小数点`）

  インデックス走査間にそれぞれのインデックス行の処理に対するプランナの推測を設定します。 デフォルトは0.005です。

`cpu_operator_cost`（`浮動小数点`）

  問い合わせ時に実行される各演算子や関数の処理コストに対するプランナの推測を設定します。デフォルトは0.0025です。

`effective_cache_size` (`整数`)

  単一の問い合わせで利用できるディスクキャッシュの実効容量に関するプランナの仮定を設定します。 これは、インデックスを使用するコスト推定値の要素となります。 より高い値にすれば、よりインデックススキャンが使用されるようになり、より小さく設定すれば、シーケンシャルスキャンがより使用されるようになります。 このパラメータを設定する時には、PostgreSQLの共有バッファとPostgreSQLデータファイルに使用されるカーネルのディスクキャッシュの量の両方を考慮しなければなりません。 また、利用可能な領域を共有しますので、異なるテーブルに対して同時に実行される問い合わせの総定数も考慮してください。 このパラメータは、PostgreSQLで割り当てられる共有メモリの大きさには影響を与えません。また、カーネルのディスクキャッシュを予約したりもしません。 これは推定目的のみで使用されます。 デフォルトは128メガバイト（`128MB`）です。

## 18.6.3. 遺伝的問い合わせオプティマイザ

遺伝的問い合わせオプティマイザ（GEQO）はヒューリスティック（発見的）検索法を用いた問い合わせ計画を行なう演算手法です。 通常のしらみつぶしの検索演算手法で見いだされる計画よりも時として劣った計画を作成するという代償を払いますが、この手法は（多くのリレーションを結合するような）複雑な問い合わせに対し計画時間を軽減します。 同時に、GEQOの検索は無作為化しますので、計画の決定性は変動します。 より詳細は第49章を参照してください。

`geqo`（`論理値`）

  遺伝的問い合わせ最適化を有効もしくは無効にします。デフォルトは有効です。 運用時には無効にしないことが通常最善です。`geqo_threshold`変数は、GEQO使用を制御するためよりきめ細かな方法を提供します。

`geqo_threshold`（`整数`）

  少なくともこれだけの数の`FROM`項目数で問い合わせを計画するのに遺伝的問い合わせ最適化を使用します。 （`FULL OUTER JOIN`の生成子は、1つの`FROM`項目として計算することに注意してください。）デフォルトは12です。もっと単純な問い合わせでは、決定論的、しらみつぶしの検索プランナを使用するのが最善ですが、多くのテーブルを持つ問い合わせでは、決定論的プランナは非常に時間がかかります。

`geqo_effort` （`整数`）

  GEQOにおける計画時間と問い合わせ計画の品質間のトレードオフを制御します。この変数は1から10までの範囲の整数でなければなりません。デフォルトの値は5です。値を大きくすると、問い合わせ計画作成により多くの時間を費すことになりますが、より効率的な問い合わせ計画が選択される可能性が増加します。

  実際`geqo_effort`は直接何も行いません。それはGEQOの動作に影響を与える他の変数に対し、デフォルトの値を計算するためにのみ使用されます（以下で説明します）。お望みであれば、代わりに手作業で他のパラメータを設定できます。

`geqo_pool_size`（`整数`）

  GEQOで使用されるプール容量を管理します。それは遺伝的個体群内の個体数です。最低でも2つはなければならず、よく100から1000までの値が使用されます。もし（デフォルトの設定である）零に設定されると、`geqo_effort`および問い合わせの中のテーブル数に基づいて、適切な値が選択されます。

`geqo_generations`（`整数`）

  GEQOで使用される世代の数を管理します。それはアルゴリズムの反復数です。最低でも1はなければならず、よくプールサイズと同じ範囲の値が使用されます。これを0に設定（デフォルトの設定）すると、適切な値が`geqo_effort`に基づいて選択されます。

`geqo_selection_bias`（`浮動小数点`）

  GEQOで使用される淘汰の偏りを管理します。淘汰の偏りは個体群内の（遺伝的な）自然淘汰です。値は1.50から2.00で、2.00がデフォルトです。

## 18.6.4. その他のプランナオプション

`default_statistics_target`（`整数`）

  `ALTER TABLE SET STATISTICS`で列特定の目的セットを所有していなかったテーブル列に対し、デフォルトの統計対象を設定します。 より大きい値は`ANALYZE`に必要なの時間を増加させますが、プランナの予測の品質を向上させます。 デフォルトは100です。 PostgreSQLの問い合わせプランナによる統計情報の使用法に関するより詳細な情報は、項14.2を参照してください。

`constraint_exclusion` (`enum`)

  問い合わせを最適化するため、テーブル制約に対しての問い合わせプランナの使用を制御します。`constraint_exclusion`に許容される値は、`on`（全てのテーブルに対し制約を検査する）、`off`（決して制約を検査しない）、および`partition`（継承された子テーブルおよび`UNION ALL`副問い合わせのみ制約を検査する）です。`partition`がデフォルトです。

  このパラメータが特定のテーブルに対して許される時、プランナはそのテーブルの`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`はデフォルトで、テーブルパーティショニングを実装するためによく使用される場合のみで有効です。 すべてのテーブルを有効にすることは、計画作成において単純な問い合わせでは無視できない程の余計なオーバーヘッドをもたらします。 パーティショニングされたテーブルがない場合、完全に無効にする方が良いでしょう。

  制約排除とテーブル分割についてのより進んだ情報は項5.9.4を参照ください。

`cursor_tuple_fraction`（`浮動小数点`）

  検索されるカーソル行の割合のプランナの見積もりを設定します。 デフォルトは0.1です。 この設定をより小さくすると、プランナはカーソルに対し"起動を高速にする"計画を使用するようになりがちになります。 この場合先頭の数行の取り出しは高速になりますが、行全体を取り出す場合に時間がかかるようになる可能性があります。 この値をより大きくすると、推定時間全体がより強調されるようになります。 最大の設定である1.0の場合、カーソルは通常の問い合わせとまったく同様に計画されます。 つまり、推定時間全体のみが考慮され、先頭の行の取り出しにかかる時間は考慮されなくなります。

`from_collapse_limit`（`整数`）

  プランナは、`FROM`リストがこの数の項目より少ない結果の場合、副問い合わせを上位の問い合わせに併合します。 より小さい値は計画時間を縮小させますが、劣った問い合わせ計画をもたらす可能性があります。 デフォルトは8です。 詳細は項14.3を参照してください。

  この値をgeqo_thresholdか、それ以上に設定するとGEQOプランナ使用の誘引となり、非決定的計画をもたらします。項18.6.3を参照してください。

`join_collapse_limit` (`整数`)

  最終的にリストがこの項目数以下になる時、プランナは、明示的な`JOIN`構文（`FULL JOIN`を除く）を`FROM`項目のリストに直します。 この値を小さくすれば計画作成時間は減少しますが、劣った問い合わせ計画が作成される可能性があります。

  デフォルトでは、この値は`from_collapse_limit`と同じ値に設定されており、殆どの場合に適切です。 これを1に設定すると明示的な`JOIN`の再順序付けは行われなくなります。 したがって、問い合わせで指定された明示的結合順序は、関係（リレーション）が結合される実際の順序となります。 問い合わせプランナは常に最適な結合順序を選択するとは限りません。 上級ユーザなら暫定的にこの変数を1に設定し、明示的に希望とする結合順序を指定してもよいでしょう。 詳細は項14.3を参照してください。

  この値をgeqo_thresholdか、それ以上に設定するとGEQOプランナ使用の誘引となり、非決定的計画をもたらします。項18.6.3を参照してください。

前のページ | ホーム | 次のページ
ログ先行書き込み（WAL） | 上に戻る | エラー報告とログ取得