データベースサーバが共有メモリバッファのために使用するメモリ量を設定します。 デフォルトは一般的に128メガバイト(128MB)です。 しかし、稼働中のカーネルの設定がこの値をサポートしていない場合、より少なくなることがあります（initdbの過程で決定されます）。 この設定は最低限128キロバイトなければなりません。 しかし、良い性能を引き出すためには、最小値よりかなり高い値の設定が通例必要です。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 （BLCKSZがデフォルト値と異なる場合、この最小値も異なる値になります。） このパラメータはサーバ起動時のみ設定可能です。

1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。 しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。 shared_buffersをより大きく設定する場合は、大抵max_wal_sizeも合わせて増やす必要があります。これは、新規または変更された多量のデータを書き出す処理をより長い時間に渡って分散させるためです。

1GB未満のRAMのシステムでは、オペレーティングシステムに十分な余裕を残すために、RAMに対してより小さい割合を設定することが適切です。

主共有メモリ領域に対してhuge pageを要求するかどうかを管理します。 可能な値はtry (デフォルト)、on、offです。 huge_pagesをtryに設定すると、サーバはhuge pageの要求を試み、失敗したらデフォルトに戻します。 onにすると、要求に失敗した場合にサーバの起動ができなくなることになります。 offならhuge pageの要求は行いません。

今のところこの機能はLinuxとWindowsでのみサポートされています。 他のシステムではtryと設定しても無視されます。 Linuxではこの機能はshared_memory_typeがmmap（デフォルトです）に設定されている時にのみサポートされます。

huge pageを使うと、ページテーブルが小さくなり、メモリ管理に使用されるCPU時間が少なくなり、性能が向上します。 詳細は、19.4.5を見てください。

huge pageはWindowsではlarge pageとして知られています。 それを使用するには、PostgreSQLを実行するWindowsユーザアカウントに「メモリ中のロックページ」権限を与える必要があります。 ユーザに「メモリ中のロックページ」権限を与えるには、Windowsのグループポリシーツール(gpedit.msc)を利用できます。 Windowsサービスとしてではなく、スタンドアローンプロセスとしてデータベースサーバをコマンドプロンプトで起動するには、コマンドプロンプトを管理者として実行するか、ユーザアクセス管理(UAC)を無効にしておかなければなりません。 UACが有効ならば、通常のコマンドプロンプトは起動時にユーザの「メモリ中のロックページ」権限を剥奪します。

この設定は主共有メモリ領域にのみ影響することに注意してください。 Linux、FreeBSD、Illumosのようなオペレーティングシステムでは、PostgreSQLからの明示的な要求なしにhuge page（「super」 pageあるいは「large」pageとしての知られています）が通常のメモリ獲得の際に使用できます。 Linuxでは、これは「transparent huge pages」 (THP)と呼ばれています。 この機能は、あるLinuxバージョンのあるユーザにおいてPostgreSQLの性能低下をもたらすことが知られています。 ですから、この機能の利用は（huge_pagesの明示的な利用と違って）今の所推奨されていません。

huge_pagesが有効なときにhuge pageのサイズを制御します。 デフォルトはゼロ(0)です。 0に設定すると、システムのデフォルトのhuge pageのサイズが使われます。 このパラメータはサーバ起動時のみ設定可能です。

現代の64ビットサーバアーキテクチャにおける可能な一般的なページサイズには以下が含まれます。 2MBと1GB (IntelとAMD)、16MBと16GB (IBM POWER)、64kB、2MB、32MBそして1GB (ARM)。 使い方とサポートに関する詳細な情報に関しては19.4.5を参照してください。

今の所Linuxでサポートされるデフォルトの設定値はありません。

それぞれのデータベースセッションが使用する一時バッファの最大メモリ量を設定します。 一時バッファは、一時テーブルにアクセスする時にのみ使用されるセッションローカルのバッファです。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 デフォルトは8メガバイト（8MB）です。 （BLCKSZが8kBでなければ、それに比例して増減します。） 設定はそれぞれのセッション内で変更できますが、そのセッション内で一時テーブルが最初に使用されるまでになります。それより後に値の変更を試みても、そのセッションでは効果がありません。

セッションは、temp_buffersを上限として、必要に応じて一時バッファを確保します。 多くの一時バッファを実際に必要としないセッションで大きな値を設定するコストとは、temp_buffersの増分毎に、1つのバッファ記述子、約64バイトだけです。 しかし、バッファが実際に使用されると、それに対して追加の8192バイト（汎用的に言えばBLCKSZバイト）が消費されます。

同時に「プリペアド」状態にできるトランザクションの最大数を設定します（PREPARE TRANSACTIONを参照してください）。 このパラメータをゼロ（これがデフォルトです）に設定すると、プリペアドトランザクション機能が無効になります。 このパラメータはサーバ起動時のみ設定可能です。

プリペアドトランザクションの使用を意図しないのであれば、このパラメータはプリペアドトランザクションが偶然に作成されないようゼロに設定すべきです。 プリペアドトランザクションを使用する場合、全てのセッションがプリペアドトランザクションを保留できるように、max_prepared_transactionsを少なくともmax_connectionsと同じ大きさに設定するのが良いでしょう。

スタンバイサーバを運用している場合、このパラメータはプライマリサーバ上の設定よりも同等かもしくはより高水準に設定しなければなりません。そうしないと問い合わせがスタンバイサーバ内で受け入れられません。

一時ディスクファイルに書き込む前に、問い合わせ操作（ソートやハッシュなど）で使用される最大メモリ量を設定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト値は4MB(4MB)です。 複雑な問い合わせでは、同時に複数のソート操作とハッシュ操作が実行される可能性があります。 各操作は通常、データを一時ファイルに書き込む前にこの値で指定された量のメモリを使用できます。 また、複数の実行中のセッションが同時にこのような操作を実行することもあります。 したがって、使用されるメモリの合計量はwork_memの数倍になる可能性があります。 値を選択する時には、この事実に留意することが必要です。 ソート操作はORDER BY、DISTINCT、およびマージ結合に対して使われます。 ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、メモ化（memoize）ノードおよびIN副問い合わせのハッシュに基づいた処理で使用されます。

一般的に、ハッシュに基づく操作はソートに基づく操作よりも利用可能なメモリに敏感です。 ハッシュテーブルのメモリ制限は、work_memにhash_mem_multiplierを乗算することで計算されます。 これにより、ハッシュに基づく操作では通常のwork_memに基づく量を超える量のメモリが使用される可能性があります。

ハッシュに基づく操作が利用できる最大のメモリ量を計算するために使用します。 最終的な制限はwork_memにhash_mem_multiplierを掛けて決定されます。 デフォルト値は2.0で、ハッシュに基づく操作が通常のwork_memに基づく値の2倍使用することになります。

問い合わせ操作によって日常的にメモリ不足になるような環境、とりわけ単にwork_memを増やしたことによってメモリ逼迫（メモリ逼迫が典型的には間欠的なメモリ不足エラーの発生の形で起こる）が起きる場合にはhash_mem_multiplierを増やすことを考慮してください。 デフォルトの2.0が色々なワークロードが混在している場合には効果的かも知れません。 より大きな2.0から8.0、あるいはそれ以上の設定はwork_memがすでに40MB以上に増やしてあるような環境で効果的かも知れません。

VACUUM、CREATE INDEX、およびALTER TABLE ADD FOREIGN KEYの様な保守操作で使用されるメモリの最大容量を指定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト値は64メガバイト（64MB）です。 1つのデータベースセッションでは、一度に1つしか上記操作はできませんし、通常インストレーションでこうした操作が同時に非常に多く発生することはありませんので、これをwork_memよりもかなり多めの値にしても安全です。 大きい値を設定することでvacuum処理と、ダンプしたデータベースのリストア性能が向上します。

自動バキュームが稼働すると、最大でこのメモリのautovacuum_max_workers倍が配分されるので、デフォルトの値をあまり高く設定しないよう注意してください。 別の設定項目autovacuum_work_memで制御するのが良いかもしれません。

無効タプル識別子の集合に対しては、VACUUMは最大でも1GBまでしか使用することができないことに注意してください。

個々の自動バキュームワーカープロセスが使用する最大のメモリ量を指定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルトは-1で、maintenance_work_memが代わりに使われる設定になります。 別の文脈で実行されるVACUUMにはこの設定は影響しません。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

無効タプル識別子の集合に対しては、自動バキュームは最大でも1GBまでしか使用することができません。 ですからautovacuum_work_memをそれ以上に指定しても、自動バキュームがテーブルを走査して収集できる無効タプルの数には影響を与えません。

VACUUMコマンドおよびANALYZEコマンドで使用されるバッファアクセスストラテジの大きさを指定します。 0を設定すると、それらの操作で任意の数のshared_buffersを使用できることになります。 それ以外の場合は、有効なサイズは128 kBから16 GBまでの範囲です。 指定されたサイズがshared_buffersのサイズの1/8を超える場合、サイズは黙ってその値に制限されます。 デフォルト値は256 kBです。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 このパラメータはいつでも設定できます。 このパラメータは、BUFFER_USAGE_LIMITオプションを渡すことによって、VACUUMおよびANALYZEに対して上書きできます。 設定を高くすると、VACUUMおよびANALYZEの実行速度が速くなりますが、設定を高くしすぎると、他の多くの有用なページが共有バッファから削除されてしまう可能性があります。

デコードされた更新がローカルディスクに書かれる前にロジカルデコーディングが使用する最大のメモリ量を指定します。 これにより、ロジカルストリーミングレプリケーションの接続が使用する最大メモリが制限されます。 デフォルトは64メガバイト(64MB)です。 個々のレプリケーション接続がここで指定した単一のバッファだけを使用し、インストールは通常たくさんの接続を並行して使わないので（max_wal_sendersで制限されます）、この値をwork_memよりもずっと大きくしても安全で、それによってデコードされた更新がディスクに書かれる量が削減されます。

サーバの実行スタックの最大安全深度を指定します。 このパラメータの理想的な設定はカーネルにより強要される実際のスタック容量の（ulimit -sもしくはそれと同等の機能で設定された）限界から、1メガバイト程度の安全余裕度を差し引いたものです。 この安全余裕度は、サーバがすべてのルーチンではスタック深度を検査をせず、再帰を行う可能性のある重要なルーチンでのみ検査をするために必要となるものです。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト設定は2メガバイト（2MB）で、かなり控え目、かつクラッシュの危険がなさそうな設定です。 しかし、複雑な関数の実行を許容するには小さ過ぎるかも知れません。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

max_stack_depthを実際のカーネルの制限よりも高い値に設定した場合、暴走した再帰関数により、個々のバックエンドプロセスがクラッシュするかもしれません。 PostgreSQLがカーネルの制限を決定することができるプラットフォームでは、この変数を危険な値に設定させません。 しかし、すべてのプラットフォームがこの情報を提供できるわけではありません。 このため、値を選ぶ時には注意が必要です。

PostgreSQLの共有バッファおよび他の共有データを保持する主共有メモリ領域のためにサーバが使用すべき共有メモリの実装を指定します。 可能な値はmmap（mmapを使って獲得した無名共有メモリ）、sysv （shmgetを使って獲得したSystem V共有メモリ）、windows （Windows共有メモリ）です。 すべての値がすべてのプラットフォームでサポートされているわけではありません。 サポートされている最初のオプションがそのプラットフォームのデフォルトです。 どのプラットフォームでもデフォルトになっていないsysvオプションの利用は一般に推奨されません。 通常、デフォルトではないカーネルの設定が大きなアロケーションでは必要になるからです。 （19.4.1参照。）

サーバが使う動的共有メモリの実装を指定します。可能な値はposix (shm_openで獲得するPOSIX共有メモリ)、sysv(shmgetで獲得するSystem V共有メモリ)、windows (Windows共有メモリ)、 mmap(データディレクトリ内のメモリマップファイルを使ってシミュレートする共有メモリ)です。 すべての値がすべてのプラットフォームでサポートされているわけではありません。 そのプラットフォームでの推奨実装が通常デフォルトになります。 どのプラットフォームでもデフォルトになっていないmmapは、オペレーティングシステムが変更されたページをディスクに継続的に書き込み、I/O負荷を増加させるので一般的には利用が推奨されていません。 しかし、デバッグ目的のためにpg_dynshmemディレクトリがRAMディスク上にある場合や、他の共有メモリ機能が使えない場合は有用かもしれません。

サーバ起動時にパラレルクエリ用に獲得するメモリの量を指定します。 このメモリ領域不足していたり並列実行される問い合わせで使い尽くされると、新しいパラレルクエリはdynamic_shared_memory_typeで設定された方法でオペレーティングシステムから一時的に共有メモリを獲得しようとします。 これはメモリ管理のオーバーヘッドにより遅くなる可能性があります。 起動時にmin_dynamic_shared_memoryで獲得するメモリは、サポートするオペレーティングシステムに対するhuge_pagesの設定に影響を受けます。 huge pageを自動管理するオペレーティングシステム上でより大きなページにより恩恵を被る可能性が大きいです。 デフォルト値は0（none）です。 このパラメータはサーバ起動時にのみ設定可能です。

あるプロセスが一時ファイルとして使用できるディスクの最大容量を設定します。 例えば、ソートやハッシュの一時ファイルであったり、カーソルを保持する格納ファイルです。 この制限値を超えようとするトランザクションはキャンセルされます。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 -1（デフォルトです）の場合は制限がありません。 この設定はスーパーユーザと、適切なSET権限を持つユーザのみ変更可能です。

この設定により、ある PostgreSQL セッションによって使用される一時ファイルの合計の容量が常に制約されることになります。 なお、問い合わせの実行において暗黙的に使用される一時ファイルとは異なり、一時テーブルとして明示的に使用されるディスク容量は、この制限には含まれません。

それぞれのサーバ子プロセスが同時にオープンできるファイル数の最大値をセットします。 デフォルトは1000ファイルです。 もしもカーネルがプロセス毎の安全制限を強要している場合、この設定を気にかける必要はありません。 しかし、いくつかのプラットフォーム（特にほとんどのBSDシステム）では、もし多くのプロセス全てがそれだけ多くのファイルを開くことを試みたとした場合、実際にサポートできるファイル数より多くのファイルを開くことを許しています。もしも「Too many open files」エラーが発生した場合、この設定を削減してみてください。 このパラメータはサーバ起動時のみ設定可能です。

コストの限度を越えた場合、プロセスがスリープする時間の長さです。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は0で、コストに基づいたvacuum遅延機能を無効にします。 正の整数はコストに基づいたvacuumを有効にします。

コストに基づいたバキューム処理を使用する場合、vacuum_cost_delayの適切な値は通常かなり小さくなり、おそらく1ミリ秒以下になります。 バキュームによるリソース消費の調整は、他のバキュームのコストパラメータを変更して行うことが最善です。 vacuum_cost_delayを1ミリ秒以下に設定することは可能ですが、そうした遅延は古いプラットフォームでは正確には計測されないかも知れません。 そうしたプラットフォームでは、VACUUMのリソース消費制限を1ミリ秒のときに得られる値以上にするには、他のVACUUMコストパラメータの変更が必要となるでしょう。 とは言うものの、使用するプラットフォームで常に計測できる範囲でvacuum_cost_delayをできるだけ小さくするようにしてください。 大きな遅延は助けになりません。

共有バッファキャッシュの中のバッファにvacuumを掛ける予測コストです。バッファプールのロック、共有ハッシュテーブルの検索、およびページ内容走査のコストを示します。デフォルトの値は1です。

ディスクから読み込まれなければならないバッファにvacuumを掛ける予測コストです。これが示すものは、バッファプールロックの試み、共有ハッシュテーブルの参照、ディスクから目的ブロックの読み込み、そしてその内容走査です。デフォルトの値は2です。

vacuumが、先だって掃除したブロックを変更するのに必要な推定コストです。 ダーティブロックを再度ディスクにフラッシュするのに必要な余分なI/Oを表します。デフォルトの値は20です。

vacuumを掛けるプロセスをスリープさせることになる累計されたコストです。 デフォルトの値は200です。

バックグラウンドライタの動作周期間の遅延を指定します。 それぞれの周期でライタは、（以下のパラメータで管理される）一部のダーティバッファの書き込みを行います。 そしてbgwriter_delayの長さスリープした後、これを繰りかえします。 しかし、バッファプールにダーティバッファが存在しない場合、bgwriter_delayに係わらずより長くスリープします。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は200ミリ秒（200ms）です。 多くのシステムで、スリープ遅延の実精度は10ミリ秒です。 bgwriter_delayの値の設定を10の倍数としない場合、次に大きい10の倍数に設定した結果と同一になるかもしれないことを覚えておいてください。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインで設定可能です。

それぞれの周期で、この数以上のバッファはバックグラウンドライタにより書き込まれません。 ゼロに設定することでバックグラウンド書き込みは無効になります。 （分離し、そして専用の補助プロセスにより管理されるチェックポイントは影響を受けません。） デフォルト値は100バッファです。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

各周期で書き出されるダーティバッファ数は、最近の周期でサーバプロセスが必要とした新しいバッファ数を基にします。 次の周期で必要となるバッファ数を推定するために、最近必要とされた平均がbgwriter_lru_multiplierと掛け合わせられます。 ダーティバッファの書き出しは、同数の整理済み、再利用可能なバッファが利用できるようになるまで行われます。 （しかし1周期にbgwriter_lru_maxpagesを超えるバッファ数を書き出しません。） したがって、1.0と設定することは、必要と予想されるバッファ数の書き込みについて「必要なときに必要なだけ」というポリシーを表します。 より大きな値は突発的な要求に対する多少の緩衝材を提供します。 より小さな値はサーバプロセスでなされる書き込みを意図的に残します。 デフォルトは2.0です。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

バックグラウンドライタがこの値より多く書く度に、OSが記憶装置に書き込むことを強制しようとします。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な設定値は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は、Linuxでは512kBで、それ以外は0です。 (BLCKSZが8kBでなければ、この設定のデフォルト値と最大値がBLCKSZに比例して変更されます。) このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

この量を超えるデータが単一のバックエンドによって書き込まれたときはいつでも、OSが記憶装置に書き込むことを強制します。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはバックグラウンドで実行される大きなバッチの中でOSがデータを書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な範囲は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は0です(すなわち書き出し制御を行いません)。 (BLCKSZが8kBでなければ、最大値がBLCKSZに比例して変更されます。)

PostgreSQLが同時実行可能であると想定する同時ディスクI/O操作の数を設定します。 この値を大きくすると、あらゆる個別のPostgreSQLセッションが並行して開始を試みるI/O操作の数が増加します。 設定可能な範囲は1から1000まで、または非同期I/Oリクエストの発行を無効にするゼロです。 現在、この設定はビットマップヒープスキャンのみに影響します。

磁気ディスクドライブにおいては、データベースに使用されるRAID 0ストライプ、RAID 1ミラーを構成する個々のドライブ数から始めると良いでしょう。（RAID 5ではパリティ用のドライブを数に含めません） しかし、同時実行セッションで発行される複数の問い合わせでデータベースが頻繁にビジーとなる場合、小さめの値で十分ディスクアレイがビジーになるかもしれません。 ディスクをビジーにするのに必要な値より大きな値を設定しても、余計なCPUオーバーヘッドを発生させるだけです。 SSDやそれ以外のメモリベースの記憶装置は、多くの同時リクエストをこなすことができるので、最適な値は数百になるかもしれません。

非同期I/Oは実質的にposix_fadvise関数に依存します。 これは一部のオペレーティングシステムには存在しません。 この関数が存在しない場合、この値をゼロ以外に設定するとエラーとなります。 一部のオペレーティングシステム（例えばSolaris）では存在するけれども、実際何も行わないものもあります。

デフォルトは、サポートされているシステムでは1、そうでなければ0です。 この値は、テーブル空間パラメータの同じ名前のパラメータを設定することで、特定のテーブル空間内のテーブルに対して上書きできます。 (ALTER TABLESPACEを参照ください)。

effective_io_concurrencyと似ていますが、多くのクライアントセッションのために行われる保守作業で適用されるところが異なります。

サポートしているシステムではデフォルトは10で、それ以外は0です。 この値は同じ名前のテーブル空間パラメータを使って、特定のテーブル空間にあるテーブルのために置き換えることができます。（ALTER TABLESPACEを参照してください。）

システムがサポートするバックグラウンドプロセスの最大数を指定します。 このパラメータはサーバ起動時のみ設定可能です。 デフォルトは8です。

スタンバイサーバを起動しているときは、このパラメータを、プライマリサーバの設定値と同じかそれ以上にしなければなりません。 さもなければ、スタンバイサーバで問い合わせの実行ができなくなります。

この値を変更する際は、max_parallel_workers、max_parallel_maintenance_workers、max_parallel_workers_per_gatherを変更することも考慮してください。

一つのGatherまたはGather Mergeノードに対して起動できるワーカー数の最大値を設定します。 パラレルワーカーは、max_parallel_workersで上限が決まるmax_worker_processesで確立されたプロセスのプールから取得されます。 実行時には、要求された数のワーカーは取得できないかもしれないことに注意してください。 そうなると、実行プランは期待していたよりも少ない数のワーカーで実行されることになり、効率は悪化するかもしれません。 デフォルト値は2です。 この設定値を0にすると、パラレルクエリの実行は行われません。

パラレルクエリの実行により、パラレルクエリではない場合に比べて非常に多くのリソースが使用されるかもしれないことに注意してください。 これは、個々のワーカープロセスは完全に別個のプロセスであり、システムに対してユーザセッションが追加されたのと大体同じくらいの影響があるからです。 この設定値を選択する際には、他のリソースの消費量を制御する他の設定値、たとえばwork_memを設定するときと同様に、この点を考慮しておく必要があります。 work_memのような設定値によるリソース制限は、個々のワーカーに対して個別に適用されます。 つまり、ひとつのプロセスに対するよりも、すべてのプロセスの全体のリソース消費はずっと多いかもしれないということです。 たとえば、あるパラレルクエリが4つのワーカーを使っているとすると、ワーカーを使わない場合に比べて、最大5倍のCPU時間、メモリ、I/Oバンド幅、その他を使うかもしれません。

パラレルクエリに関する更なる情報については、第15章をご覧ください。

単一のユーティリティコマンドで使用されるパラレルワーカーの最大数を設定します。 今の所、パラレルワーカーの利用をサポートしているパラレルユーティリティコマンドは、CREATE INDEXがB-treeインデックスを構築するときと、FULLオプションなしのVACUUMです。 パラレルワーカーは、max_worker_processesで確立したプロセスのプールから取得され、max_parallel_workersによって制限されます。 要求したワーカー数は、実行時に実際には利用可能でないかも知れないことに注意してください。 この場合は、ユーティリティ操作は期待したよりも少ない数のワーカーにより実行されます。 デフォルト値は2です。 0に設定すると、ユーティリティコマンドはパラレルワーカーを使用しません。

パラレルユーティリティコマンドは同等の非パラレル操作よりもかなり多くのメモリを消費すべきでないことに留意してください。 この戦略は、一般的にワーカー毎にリソース制限を適用するパラレルクエリとは異なります。 パラレルワーカープロセスの数にかかわらず、パラレルユーティリティコマンドは、その全体でリソース制限maintenance_work_memが適用されるとみなします。 しかし、パラレルユーティリティコマンドは、依然としてかなり多くのCPUリソースとI/Oバンド幅を消費するかも知れません。

パラレルクエリ操作用にシステムがサポートできる最大のワーカー数を設定します。 デフォルト値は8です。 この値を増減するときは、max_parallel_maintenance_workersとmax_parallel_workers_per_gatherを調整することを考慮してください。 また、この設定値をmax_worker_processesよりも高い値にしても効果がないことに注意してください。 max_worker_processesで決まるワーカープロセスのプールから、パラレルワーカーが使われるからです。

ワーカープロセスを待つ代わりに、GatherノードとGather Mergeノード配下の問い合わせプランをリーダープロセスが実行できるようにします。 デフォルトはonです。 この値をoffにすると、リーダーがタプルを十分早く読まないためにワーカーがブロックされる可能性を減らすことができますが、リーダープロセスは最初のタプルが生成される前にワーカープロセスが起動するのを待つ必要があります。 これがリーダーの性能を助けるのか、阻害要因になるかは計画型、ワーカーの数、問い合わせの実行時間の長さによります。

スナップショットを使用する際に、「snapshot too old」エラーが起こるリスク無しに問い合わせスナップショットが利用できる最小の期間を設定します。 この制限値を越えてデッド状態のままになったデータはバキュームしてしまうことが許可されます。 これにより、長い間残っていたスナップショットによりデータが溢れてしまうのを防ぐことができます。 スナップショットから見えるデータが消えることによる不正な結果を防ぐため、スナップショットがこの制限値よりも古く、かつこのスナップショットが作られた以降に変更されたページを読むためにスナップショットが使用されるときはエラーが発生します。

この値が単位なしで指定された場合は、分単位であるとみなします。 -1（デフォルトです）を設定するとこの機能が無効になり、実質的にスナップショットの寿命を無限にします。 このパラメータはサーバ起動時のみ設定可能です。

実際の環境でのおすすめの値はおそらく数時間から2, 3日の間となるでしょう。 小さな値(たとえば0や1min)は、テストの際に有用だということで許可されています。 60dのような大きな値の設定もできますが、多くのワークロードにおいて、大きなデータ溢れやトランザクションIDの周回がそれよりはずっと短い期間で起こる可能性があることに注意してください。

この機能が有効であると、リレーションの終端部にあるフリースペースはオペレーティングシステムには返却されません。 そうしないと、「snapshot too old」の条件の検出に必要な情報を削除してしまうことになるからです。 明示的に解放されない限り（たとえばVACUUM FULLによって）、リレーションに割り当てられた領域は、そのリレーションの中での再利用に限定して紐付けられます。

この設定は、どのような状況でもエラーが検出されることを保証するものではありません。 （たとえば）マテリアライズされた結果集合を持つカーソルから正しい結果を得ることができるのであれば、たとえ参照している元のテーブルからVACUUMによって行が削除されたとしてもエラーにはなりません。 ある種のテーブルでは、早期にVACUUMできないので、この設定の影響を受けません。 例としては、システムカタログが挙げられます。 このようなテーブルにおいては、この設定によってデータ溢れを防ぐことも、スキャンの際に「snapshot too old」エラーを起こす可能性を作り出すこともできません。