3.4. 実行時の設定

問い合わせオプティマイザがインデックススキャンの間にそれぞれ のインデックスタプルを処理するコストの概算を設定します。 これは順ページ取り出しのコストとの比率で評価されます。

オプティマイザが WHERE 句の中のそれぞれの演算子を処理する コストの概算を設定します。これは順ページ取り出しのコスト との比率で評価されます。

問い合わせオプティマイザが問い合わせの間に各々のタプルを処理 するコストを設定します。これは順ページ取り出しのコスト との比率で評価されます。

ディスクキャッシュの実効サイズに関するオプティマイザの 推測を設定します(すなわち、Postgres データファイルに使われるカーネルのディスクキャッシュです)。 これは、通常は一単位 8kB のディスクページを基準に評価します。

問い合わせプランナのハッシュ結合型のプランの使用を有効もしくは 無効にします。デフォルトでは有効です。これは大体問い合わせプランナ のデバッグで役に立ちます。

問い合わせプランナのインデックススキャン型のプランの使用を有効 もしくは無効にします。デフォルトでは有効です。これは大体問い合わせ プランナのデバッグで役に立ちます。

問い合わせプランナのマージ結合型のプランの使用を有効 もしくは無効にします。デフォルトでは有効です。これは大体問い合わせ プランナのデバッグで役に立ちます。

問い合わせプランナのネストループ結合計画の使用を有効もしくは 無効にします。ネストループ結合を完全に抑えることは不可能ですが、 この変数を無効にすることにより他の方法があった場合プランナが ネストループ結合を使わないようにします。デフォルトでは有効です。 これは大体問い合わせプランナのデバッグで役に立ちます。

問い合わせプランナが順スキャン型のプランの使用を有効もしくは 無効にします。順スキャンを完全に抑えることは不可能ですが、 この変数を無効にすることにより他の方法があった場合プランナが 順スキャンを使わないようにします。デフォルトでは有効です。 これは大体問い合わせプランナのデバッグで役に立ちます。

問い合わせプランナが明示的なソート処理の使用を有効もしくは 無効にします。明白なソートを完全に抑えることは不可能ですが、 この変数を無効にすることにより他のメソッドがあった場合プランナが 順スキャンを使わないようにします。デフォルトでは有効です。 これは大体問い合わせプランナのデバッグで役に立ちます。

問い合わせプランナが TID スキャン計画の型の使用を有効もしくは 無効にします。デフォルトでは有効です。 これは大体問い合わせプランナのデバッグで役に立ちます。

問い合わせプランナが、しらみつぶしの検索を行なうことなく 問い合わせ計画を作成するアルゴリズムである遺伝的問い合わせ 最適化の使用を有効もしくは無効にします。デフォルトは有効です。

遺伝的問い合わせ最適化のアルゴリズムには様々なパラメータが あります。プールのサイズは一つの個体群の個体の数です。 有効な値は 128 から 1024 までです。もしそれがゼロに設定されると (デフォルトです)、QS が問い合わせの中の FROM 句の数である 2^(QS+1) のプールサイズが選ばれます。これは世代のデフォルト を計算するために行われます。固定値は 1 から 80 の間で、 デフォルトは 40 です。世代はアルゴリズム中の反復の数を 指定します。その数は正の整数でなくてはいけません。もしゼロが 指定された場合 Effort * Log2(PoolSize) が使われます。 そのアルゴリズムの実行時間は、大雑把にいえばプールサイズと 世代の合計と同じです。この選択の偏りは個体群の中の 選択圧力です。値は 1.5 から 2.00 の間で、2.00 がデフォルトです。 アルゴリズムから再現可能な結果を得るために乱放シードを 設定することができます。もしそれが -1 に設定されると アルゴリズムは非決定論的に動作します。

少なくともこれだけの数の FROM 句の項目含む問い合わせを計画する 場合に遺伝的問い合わせ最適化を使って下さい。(JOIN 構造体は一つの FROM 句として数えられます。)デフォルトは 11 です。もっと 単純な問い合わせでは、決定論的でしらみつぶし検索プランナを使うのが 最適でしょう。

キーセット問い合わせオプティマイザ (KSQO)は問い合わせプランナが、WHERE 句にたくさんの OR がついた AND 句を持つ(例えば WHERE (a=1 AND b=2) OR (a=2 AND b=3) ...)問い合わせを UNION 文に変換させます。 このメソッドはデフォルト実装よりも速くできますが、UNION は 同一出力行を削除するために暗黙的に SELECT DISTINCT 句を追加するため 必ずしも同じ結果にはなりません。KSQO は一般的に Microsoft Accessといった、このような 形式の問い合わせをよく使う製品の作業で使われます。

KSQO アルゴリズムは OR がついた AND 句ではかつては必須でしたが、 Postgres 7.0 以降では標準プランナ がこれらの問い合わせをかなり上手に処理します。したがってデフォルト では無効です。

問い合わせオプティマイザの順不同に取りだされたディスクページ のコストの概算を設定します。これは順ページ取り出しの 倍数で評価されます。

様々な表明のチェックを有効にします。これはデバッグ用の道具です。 もし問題やクラッシュがある場合は有効にすると、プログラムの間違い が明かになるかもしれません。このオプションを使うためには、 Postgres を構築するときにマクロUSE_ASSERT_CHECKING が定義されなければいけません(--enable-cassert の設定オプションを見てください)。Postgres をそのように構築すると DEBUG_ASSERTIONSはデフォルトでは有効になります。

この値が高く設定されるほど、演算中にサーバログで様々な "デバッグ"用表示が行われます。このオプションは デフォルトではゼロで、これはデバッグ用表示なしです。 現在では 4 までの値しか意味がありません。

実行されたどのような問い合わせに対しても、問い合わせ、構文解析 ツリー、実行プラン、もしくは問い合わせ書き換えの出力のいずれか をサーバログに表示します。DEBUG_PRETTY_PRINT 選択の方が良いですが、出力形式が長くなります。

デフォルトでは、接続ログはホストの IP アドレスのみを表示 します。もしホスト名を表示させたい場合はこれを有効にしますが、 ホスト名解決の設定によっては無視できないほどの性能の低下 をもたらすこともあります。このオプションはサーバ起動時にのみ 設定できます。

成功した接続を知らせる行をサーバログに表示します。デフォルト では無効ですが、これはとても役に立ちます。このオプションは サーバ起動時にのみ設定できます。

それぞれのサーバログメッセージの冒頭にバックエンドプロセス のプロセス ID を付けます。これは、どのメッセージがどの接続 に属しているかをはっきりするのに役立ちます。デフォルトでは 無効です。

それぞれのサーバログメッセージの冒頭にタイムスタンプを付けます。 デフォルトでは無効です。

それぞれの問い合わせに対し、各々の性能統計値をサーバログに 書き出します。これは粗野なプロファイルの道具です。

接続ログメッセージの中で接続するホストのポート番号を表示 します。どのユーザが接続を開始したかを調べるためにポート番号 を使うことができます。それ以外では特に役に立たないので デフォルトでは無効になっています。このオプションはサーバ起動時 にのみ設定することができます。

Postgresはログのために syslogを使うことができます。もし このオプションが 1 に設定されていると、メッセージは syslog と 標準出力の両方に表示されます。2 の設定は syslog のみに表示 されます。(標準エラー出力に表示されるメッセージもいくつか あります。)デフォルトではゼロですが、これは syslog が無効 ということです。このオプションはサーバの起動時に設定されなくては いけません。

syslog を使うためにはPostgresの のビルドがオプション--enable-syslogで 設定されていなくてはいけません。

このオプションは syslog が有効な時に syslog "ファシリティ"を使うようにします。LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4,LOCAL5, LOCAL6, LOCAL7 の中から 選ぶことが出来、デフォルトは LOCAL0 です。使用している システムのsyslogドキュメントも 見て下さい。

このオプションは、syslog のログが有効な場合に syslogログメッセージの中の PostgreSQLメッセージを識別 するために使われるプログラム名を指定します。デフォルト は"postgres"です。

コマンドLISTEN と NOTIFY のための大量なデバッグ表示をさせます。

これは、デッドロック状態があるかどうかを調べるために ロック待ち時間をミリセカンドで計算したものです。 デッドロックのチェックは比較的遅いので、ロックを待つ度には 実行したくありません。(楽天的ですが)デッドロックは一般的な 製品アプリケーションには使われていないと仮定し、 ロック解除をするかどうか調べる前に単にロック待ちします。 。この値を増やすことにより必要の無い デッドロックのチェックで無駄にされる時間は減りますが、 本当にデッドロックがあった場合の報告が遅れます。デフォルトは 1000 (つまり一秒)で、おそらく実用の際にはこれ以上は必要 でしょう。負荷の大きいサーバではもっと必要かもしれません。 理想としてはこの設定は通常のトランザクションにかかる時間 を越えているべきです。そうすればロック待ちトランザクションが デッドロックのチェックをする前にロックが解除される可能性が 改善されます。 このオプションはサーバ起動時にのみ設定できます。

このオプションを有効にするとPostgres バックエンドがいくつかの場所でfsync() システム呼び出しを使い、 更新が物理的にディスクに書き込まれカーネルバッファキャッシュ内 に残っていないことを確認します。これはオペレーティングシステム かハードウエアクラッシュの後でもデータベースインストールが 使える可能性を大いに高くします。(データベースサーバ自体のクラッシュは 考慮されません。

しかし、このような操作は、いろいろな場所でオペレーティングシステム がバッファをフラッシュするのを待つためにブロックすることに なるので Postgres が遅くなります。fsync なしだと、オペレーティングシステムはバッファリング、ソート、 そして遅延書き込みを最高の状態で実行することができ、 性能が大きく向上します。しかし、もしシステムがクラッシュすると、 コミットされたトランザクションの最後のいくつかは一部または全部 なくなる可能性もあります。最悪の場合、データが復旧できなく なることもあります。

このオプションはPostgresユーザと開発者の コミュニティでの永遠の議論となっています。常に無効にする 人もいれば、問題が起こったときに必ず再実行できるという前堤で 大容量データのロードするときだけ無効にする人もいます。 安全を重視するために有効のままにする人もいます。そのほうが確実 なので、、PostgreSQL でも デフォルトでは有効になっています。もし使っているオペレーティング システム、ハードウエア、そして付属設備(UPS ならもっといいのですが) を信頼するならば、fsync を無効にしたほうが良いかもしれません。

Postgresバージョン 7.1 では fsync を実行した 場合の性能の低下は、以前のリリースと比べてとても小さくなりました。 もし性能の問題で fsync をやめていた方は、もう一度確認した方が 良いでしょう。

このオプションはサーバ起動時かファイル postgresql.confでのみ設定できます。

Kerberos サーバキーファイルの場所を設定します。詳細は Section 4.2.2を見て下さい。

データベースサーバがいくつの同時接続を許可するかを決定します。 デフォルトでは 32 です。この値にはコンパイルされた上限 もあり、通常は 1024 です(どちらの数字もサーバをコンパイルする 時に変えることができます)。このパラメータはサーバ起動時にのみ 設定することができます。

パーサが受け入れる式のネストの深さの最大を設定します。 デフォルトの値は通常の問い合わせでは十分ですが、必要が あれば上げて下さい。(しかし高くしすぎると、スタック オーバーフローによりバックエンドクラッシュの危険性があります。)

サーバが監視する TCP ポートデフォルトでは 5432 です。 このオプションはサーバ起動時にのみ設定できます。

データベースサーバが使う共有メモリバッファの数を設定します。 デフォルトでは 64 です。それぞれのバッファは通常 8192 バイト です。このオプションはサーバ起動時にのみ設定できます。

postmaster を「寡黙に」起動します。このオプションが 有効にされると postmaster が自動的にバックグラウンドで動き、 制御端末が切り離されます。したがって、標準出力にも標準エラー出力 にもメッセージは表示されなくなります (postmaster の -S オプションと同じ結果です)。エラーメッセージ が見えなくなるので、syslog のような ログシステムが有効でない限りこのオプションは使わないほうが 良いでしょう。

一時ディスクファイルの使用をできるだけ避けるために内部ソート とハッシュで使われるメモリの量を指定します。値はキロバイトで 指定され、デフォルトは 512 キロバイトです。複雑な問い合わせでは、 いくつかのソートかハッシュが並行して実行される可能性があり、その場合 それぞれがデータを一時ファイルに書き出す前にこの値が指定した 量のメモリを使うことが許されます。さらにそれぞれの動いている バックエンドが一つ以上のソートをしている可能性があることを 忘れないで下さい。 したがって必要なメモリ空間の合計は SORT_MEM の値の何倍にもなり得ます。

これは継承の意味論、特にサブテーブル が様々なコマンドにデフォルトで含まれているかどうか、 をコントロールします。7.1 以前のバージョンではそうではありません でした。もし古いバージョンの動作をさせたい場合はこの変数を 無効にできますが、長い目で見ればアプリケーションが サブテーブルを排除するためにONLYキーワードを 使うようにするほうが良いでしょう。更に詳しい継承の情報 については SQL 言語リファレンスとユーザガイド を参照して下さい。

SSL接続を可能にします。これを使う前に Section 3.7を読んで下さい。デフォルトでは 無効です。

これが真になっていると、サーバは TCP/IP 接続を受け入れます。 そうでなければローカルの Unix ドメインソケットの接続のみ が受け入れられます。デフォルトでは無効です。このオプションは サーバ起動時にのみ設定出来ます。

postmasterがクライアント アプリケーションからの接続を監視する Unix ドメインソケット のディレクトリを指定します。デフォルトは通常 /tmpですが、ビルド時に変えることが できます。

Unix ドメインソケットのグループ所有者を設定します。 (ソケットを所有するユーザは通常 postmaster を起動するユーザです。) オプションUNIX_SOCKET_PERMISSIONSと一緒に 使うと、このタイプのソケットの追加アクセスコントロール機構として 使うことができます。デフォルトでは空文字列で、現在のユーザの デフォルトグループを使います。このオプションはサーバ起動時に のみ設定できます。

Unix ドメインソケットのアクセス権限を設定します。Unix ドメイン ソケットは通常の Unix ファイルシステム権限の設定を使います。 このオプション値はchmod と umaskシステムコールが受けつける 数値のモード指定になるはずです。(通常使われる 8 進数の フォーマットを使うためには0(ゼロ) で始まらなくてはいけません。)

デフォルトの権限は誰でも接続できる0777 になっています。代わりとしては0770 (ユーザとグループのみです。UNIX_SOCKET_GROUP も見て下さい。)や0700(ユーザのみ)を 使うこともできます。(Unix ソケットには、実際には書き込み 権限だけが関係あり、読み込みや実行権限を設定、解除する 意味はありません。)

このアクセスコントロール機構はChapter 4 で説明されたものからは独立しています。

このオプションはサーバ起動時にのみ設定することができます。

postmasterがクライアント アプリケーションからの接続を受け付け(listen)するTCP/IP ホスト名か アドレスを指定します。デフォルトは全ての設定されたアドレス(ローカル ホストを含む)になっています。

自動 WAL チェックポイントの間の最大距離を ログファイルセグメント(それぞれのセグメントは通常 16 メガバイト です)の数で指定します。 このオプションはサーバ起動時かファイル postgresql.confでのみ設定できます。

自動 WAL チェックポイント同士の間の時間を秒で指定します。 このオプションはサーバ起動時かファイル postgresql.confでのみ設定できます。

WAL ログ用の共有メモリ内のディスクページバッファの数です。 このオプションはサーバ起動時にのみ設定できます。

もしゼロでなければ、WAL 関係のデバッグ表示を標準エラー出力に出します。

チェックポイント時にあらかじめ作られるログファイルの数です このオプションはサーバ起動時かファイル postgresql.confでのみ設定できます。

WAL 更新をディスクに書き出す方法を指定します。可能な値は下記です。 FSYNC (それぞれのコミットで fsync() を呼び出す), FDATASYNC (それぞれのコミットで fdatasync()を呼び出す ), OPEN_SYNC (open() オプション O_SYNCで WAL ファイルを書き出す), もしくは OPEN_DATASYNC (open() オプション O_DSYNCで WAL ファイル を書き出す)。 これらの全ての選択が全てのプラットフォームで使えるわけでは ありません。このオプションはサーバ起動時かファイル postgresql.confでのみ設定できます。