Sets the amount of memory the database server uses for shared memory buffers. The default is typically 128 megabytes (<literal>128MB</literal>), but might be less if your kernel settings will not support it (as determined during <application>initdb</application>). This setting must be at least 128 kilobytes. However, settings significantly higher than the minimum are usually needed for good performance. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. (Non-default values of <symbol>BLCKSZ</symbol> change the minimum value.) This parameter can only be set at server start. データベースサーバが共有メモリバッファのために使用するメモリ量を設定します。 デフォルトは一般的に128メガバイト(128MB)です。 しかし、稼働中のカーネルの設定がこの値をサポートしていない場合、より少なくなることがあります（initdbの過程で決定されます）。 この設定は最低限128キロバイトなければなりません。 しかし、良い性能を引き出すためには、最小値よりかなり高い値の設定が通例必要です。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 （BLCKSZがデフォルト値と異なる場合、この最小値も異なる値になります。） このパラメータはサーバ起動時にのみ設定可能です。

If you have a dedicated database server with 1GB or more of RAM, a reasonable starting value for <varname>shared_buffers</varname> is 25% of the memory in your system. There are some workloads where even larger settings for <varname>shared_buffers</varname> are effective, but because <productname>PostgreSQL</productname> also relies on the operating system cache, it is unlikely that an allocation of more than 40% of RAM to <varname>shared_buffers</varname> will work better than a smaller amount. Larger settings for <varname>shared_buffers</varname> usually require a corresponding increase in <varname>max_wal_size</varname>, in order to spread out the process of writing large quantities of new or changed data over a longer period of time. 1GB以上のRAMを載せた専用データベースサーバを使用している場合、shared_buffersに対する妥当な初期値はシステムメモリの25%です。 shared_buffersをこれよりも大きな値に設定することが有効なワークロードもあります。 しかし、PostgreSQLはオペレーティングシステムキャッシュにも依存するため、shared_buffersにRAMの40%以上を割り当てても、それより小さい値の時より動作が良くなる見込みはありません。 shared_buffersをより大きく設定する場合は、大抵max_wal_sizeも合わせて増やす必要があります。これは、新規または変更された多量のデータを書き出す処理をより長い時間に渡って分散させるためです。

On systems with less than 1GB of RAM, a smaller percentage of RAM is appropriate, so as to leave adequate space for the operating system. 1GB未満のRAMのシステムでは、オペレーティングシステムに十分な余裕を残すために、RAMに対してより小さい割合を設定することが適切です。

Controls whether huge pages are requested for the main shared memory area. Valid values are <literal>try</literal> (the default), <literal>on</literal>, and <literal>off</literal>. With <varname>huge_pages</varname> set to <literal>try</literal>, the server will try to request huge pages, but fall back to the default if that fails. With <literal>on</literal>, failure to request huge pages will prevent the server from starting up. With <literal>off</literal>, huge pages will not be requested. 主共有メモリ領域に対してhuge pageを要求するかどうかを管理します。 可能な値はtry (デフォルト)、on、offです。 huge_pagesをtryに設定すると、サーバはhuge pageの要求を試み、失敗したらデフォルトに戻します。 onにすると、要求に失敗した場合にサーバの起動ができなくなることになります。 offならhuge pageの要求は行いません。

At present, this setting is supported only on Linux and Windows. The setting is ignored on other systems when set to <literal>try</literal>. On Linux, it is only supported when <varname>shared_memory_type</varname> is set to <literal>mmap</literal> (the default). 今のところこの機能はLinuxとWindowsでのみサポートされています。 他のシステムではtryと設定しても無視されます。 Linuxではこの機能はshared_memory_typeがmmap（デフォルトです）に設定されている時にのみサポートされます。

The use of huge pages results in smaller page tables and less CPU time spent on memory management, increasing performance. For more details about using huge pages on Linux, see <xref linkend="linux-huge-pages"/>. huge pageを使うと、ページテーブルが小さくなり、メモリ管理に使用されるCPU時間が少なくなり、性能が向上します。 詳細は、19.4.5を見てください。

Huge pages are known as large pages on Windows. To use them, you need to assign the user right <quote>Lock pages in memory</quote> to the Windows user account that runs <productname>PostgreSQL</productname>. You can use Windows Group Policy tool (gpedit.msc) to assign the user right <quote>Lock pages in memory</quote>. To start the database server on the command prompt as a standalone process, not as a Windows service, the command prompt must be run as an administrator or User Access Control (UAC) must be disabled. When the UAC is enabled, the normal command prompt revokes the user right <quote>Lock pages in memory</quote> when started. huge pageはWindowsではlarge pageとして知られています。 それを使用するには、PostgreSQLを実行するWindowsユーザアカウントに「メモリ中のロックページ」権限を与える必要があります。 ユーザに「メモリ中のロックページ」権限を与えるには、Windowsのグループポリシーツール(gpedit.msc)を利用できます。 Windowsサービスとしてではなく、スタンドアローンプロセスとしてデータベースサーバをコマンドプロンプトで起動するには、コマンドプロンプトを管理者として実行するか、ユーザアクセス管理(UAC)を無効にしておかなければなりません。 UACが有効ならば、通常のコマンドプロンプトは起動時にユーザの「メモリ中のロックページ」権限を剥奪します。

Note that this setting only affects the main shared memory area. Operating systems such as Linux, FreeBSD, and Illumos can also use huge pages (also known as <quote>super</quote> pages or <quote>large</quote> pages) automatically for normal memory allocation, without an explicit request from <productname>PostgreSQL</productname>. On Linux, this is called <quote>transparent huge pages</quote><indexterm><primary>transparent huge pages</primary></indexterm> (THP). That feature has been known to cause performance degradation with <productname>PostgreSQL</productname> for some users on some Linux versions, so its use is currently discouraged (unlike explicit use of <varname>huge_pages</varname>). この設定は主共有メモリ領域にのみ影響することに注意してください。 Linux、FreeBSD、Illumosのようなオペレーティングシステムでは、PostgreSQLからの明示的な要求なしにhuge page（「super」 pageあるいは「large」pageとしての知られています）が通常のメモリ獲得の際に使用できます。 Linuxでは、これは「transparent huge pages」 (THP)と呼ばれています。 この機能は、あるLinuxバージョンのあるユーザにおいてPostgreSQLの性能低下をもたらすことが知られています。 ですから、この機能の利用は（huge_pagesの明示的な利用と違って）今の所推奨されていません。

Controls the size of huge pages, when they are enabled with <xref linkend="guc-huge-pages"/>. The default is zero (<literal>0</literal>). When set to <literal>0</literal>, the default huge page size on the system will be used. This parameter can only be set at server start. huge_pagesが有効なときにhuge pageのサイズを制御します。 デフォルトはゼロ(0)です。 0に設定すると、システムのデフォルトのhuge pageのサイズが使われます。 このパラメータはサーバ起動時にのみ設定可能です。

Some commonly available page sizes on modern 64 bit server architectures include: <literal>2MB</literal> and <literal>1GB</literal> (Intel and AMD), <literal>16MB</literal> and <literal>16GB</literal> (IBM POWER), and <literal>64kB</literal>, <literal>2MB</literal>, <literal>32MB</literal> and <literal>1GB</literal> (ARM). For more information about usage and support, see <xref linkend="linux-huge-pages"/>. 現代の64ビットサーバアーキテクチャにおける可能な一般的なページサイズには以下が含まれます。 2MBと1GB (IntelとAMD)、16MBと16GB (IBM POWER)、64kB、2MB、32MBそして1GB (ARM)。 使い方とサポートに関する詳細な情報に関しては19.4.5を参照してください。

Non-default settings are currently supported only on Linux. 今の所Linuxでサポートされるデフォルトの設定値はありません。

Sets the maximum amount of memory used for temporary buffers within each database session. These are session-local buffers used only for access to temporary tables. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The default is eight megabytes (<literal>8MB</literal>). (If <symbol>BLCKSZ</symbol> is not 8kB, the default value scales proportionally to it.) This setting can be changed within individual sessions, but only before the first use of temporary tables within the session; subsequent attempts to change the value will have no effect on that session. それぞれのデータベースセッションが使用する一時バッファの最大メモリ量を設定します。 一時バッファは、一時テーブルにアクセスする時にのみ使用されるセッションローカルのバッファです。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 デフォルトは8メガバイト（8MB）です。 （BLCKSZが8kBでなければ、それに比例して増減します。） 設定はそれぞれのセッション内で変更できますが、そのセッション内で一時テーブルが最初に使用されるまでになります。それより後に値の変更を試みても、そのセッションでは効果がありません。

A session will allocate temporary buffers as needed up to the limit given by <varname>temp_buffers</varname>. The cost of setting a large value in sessions that do not actually need many temporary buffers is only a buffer descriptor, or about 64 bytes, per increment in <varname>temp_buffers</varname>. However if a buffer is actually used an additional 8192 bytes will be consumed for it (or in general, <symbol>BLCKSZ</symbol> bytes). セッションは、temp_buffersを上限として、必要に応じて一時バッファを確保します。 多くの一時バッファを実際に必要としないセッションで大きな値を設定するコストとは、temp_buffersの増分毎に、1つのバッファ記述子、約64バイトだけです。 しかし、バッファが実際に使用されると、それに対して追加の8192バイト（汎用的に言えばBLCKSZバイト）が消費されます。

Sets the maximum number of transactions that can be in the <quote>prepared</quote> state simultaneously (see <xref linkend="sql-prepare-transaction"/>). Setting this parameter to zero (which is the default) disables the prepared-transaction feature. This parameter can only be set at server start. 同時に「プリペアド」状態にできるトランザクションの最大数を設定します（PREPARE TRANSACTIONを参照してください）。 このパラメータをゼロ（これがデフォルトです）に設定すると、プリペアドトランザクション機能が無効になります。 このパラメータはサーバ起動時にのみ設定可能です。

If you are not planning to use prepared transactions, this parameter should be set to zero to prevent accidental creation of prepared transactions. If you are using prepared transactions, you will probably want <varname>max_prepared_transactions</varname> to be at least as large as <xref linkend="guc-max-connections"/>, so that every session can have a prepared transaction pending. プリペアドトランザクションの使用を意図しないのであれば、このパラメータはプリペアドトランザクションが偶然に作成されないようゼロに設定すべきです。 プリペアドトランザクションを使用する場合、全てのセッションがプリペアドトランザクションを保留できるように、max_prepared_transactionsを少なくともmax_connectionsと同じ大きさに設定するのが良いでしょう。

When running a standby server, you must set this parameter to the same or higher value than on the primary server. Otherwise, queries will not be allowed in the standby server. スタンバイサーバを運用している場合、このパラメータはプライマリサーバ上の設定よりも同等かもしくはより高水準に設定しなければなりません。そうしないと問い合わせがスタンバイサーバ内で受け入れられません。

Sets the base maximum amount of memory to be used by a query operation (such as a sort or hash table) before writing to temporary disk files. If this value is specified without units, it is taken as kilobytes. The default value is four megabytes (<literal>4MB</literal>). Note that for a complex query, several sort or hash operations might be running in parallel; each operation will generally be allowed to use as much memory as this value specifies before it starts to write data into temporary files. Also, several running sessions could be doing such operations concurrently. Therefore, the total memory used could be many times the value of <varname>work_mem</varname>; it is necessary to keep this fact in mind when choosing the value. Sort operations are used for <literal>ORDER BY</literal>, <literal>DISTINCT</literal>, and merge joins. Hash tables are used in hash joins, hash-based aggregation, memoize nodes and hash-based processing of <literal>IN</literal> subqueries. 一時ディスクファイルに書き込むようになる前に、問い合わせ操作（たとえば並べ替えとハッシュテーブル操作）が使用する基本的な最大のメモリ容量を指定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト値は4メガバイト（4MB）です。 複雑な問い合わせの場合、いくつかの並べ替えもしくはハッシュ操作が並行して実行されることに注意してください。 一時ファイルへの書き込み開始の前に、それぞれの操作にこの値が指定するのと同じメモリ容量の使用が許容されます。 さらに、いくつかの実行中のセッションはこれらの動作を同時に行います。 したがって、使用されるメモリの合計は、work_memの数倍になります。値を選択する時には、この事実に留意することが必要です。 並べ替え操作はORDER BY、DISTINCT、およびマージ結合に対して使われます。 ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、メモ化（memoize）ノードおよびIN副問い合わせのハッシュに基づいた処理で使用されます。

Hash-based operations are generally more sensitive to memory availability than equivalent sort-based operations. The memory available for hash tables is computed by multiplying <varname>work_mem</varname> by <varname>hash_mem_multiplier</varname>. This makes it possible for hash-based operations to use an amount of memory that exceeds the usual <varname>work_mem</varname> base amount. 一般的に、ハッシュに基づく操作はソートに基づく操作よりも利用可能なメモリに敏感です。 ハッシュテーブルが利用可能なメモリはwork_memにhash_mem_multiplierを掛けて計算します。 これにより、ハッシュに基づく操作では通常のwork_memに基づく量を超える量のメモリが使用される可能性があります。

Used to compute the maximum amount of memory that hash-based operations can use. The final limit is determined by multiplying <varname>work_mem</varname> by <varname>hash_mem_multiplier</varname>. The default value is 2.0, which makes hash-based operations use twice the usual <varname>work_mem</varname> base amount. ハッシュに基づく操作が利用できる最大のメモリ量を計算するために使用します。 最終的な制限はwork_memにhash_mem_multiplierを掛けて決定されます。 デフォルト値は2.0で、ハッシュに基づく操作が通常のwork_memに基づく値の2倍使用することになります。

Consider increasing <varname>hash_mem_multiplier</varname> in environments where spilling by query operations is a regular occurrence, especially when simply increasing <varname>work_mem</varname> results in memory pressure (memory pressure typically takes the form of intermittent out of memory errors). The default setting of 2.0 is often effective with mixed workloads. Higher settings in the range of 2.0 - 8.0 or more may be effective in environments where <varname>work_mem</varname> has already been increased to 40MB or more. 問い合わせ操作によって日常的にメモリ不足になるような環境、とりわけ単にwork_memを増やしたことによってメモリ逼迫（メモリ逼迫が典型的には間欠的なメモリ不足エラーの発生の形で起こる）が起きる場合にはhash_mem_multiplierを増やすことを考慮してください。 デフォルトの2.0が色々なワークロードが混在している場合には効果的かも知れません。 より大きな2.0から8.0、あるいはそれ以上の設定はwork_memがすでに40MB以上に増やしてあるような環境で効果的かも知れません。

Specifies the maximum amount of memory to be used by maintenance operations, such as <command>VACUUM</command>, <command>CREATE INDEX</command>, and <command>ALTER TABLE ADD FOREIGN KEY</command>. If this value is specified without units, it is taken as kilobytes. It defaults to 64 megabytes (<literal>64MB</literal>). Since only one of these operations can be executed at a time by a database session, and an installation normally doesn't have many of them running concurrently, it's safe to set this value significantly larger than <varname>work_mem</varname>. Larger settings might improve performance for vacuuming and for restoring database dumps. VACUUM、CREATE INDEX、およびALTER TABLE ADD FOREIGN KEYの様な保守操作で使用されるメモリの最大容量を指定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト値は64メガバイト（64MB）です。 1つのデータベースセッションでは、一度に1つしか上記操作はできませんし、通常インストレーションでこうした操作が同時に非常に多く発生することはありませんので、これをwork_memよりもかなり多めの値にしても安全です。 大きい値を設定することでvacuum処理と、ダンプしたデータベースのリストア性能が向上します。

Note that when autovacuum runs, up to <xref linkend="guc-autovacuum-max-workers"/> times this memory may be allocated, so be careful not to set the default value too high. It may be useful to control for this by separately setting <xref linkend="guc-autovacuum-work-mem"/>. 自動バキュームが稼働すると、最大でこのメモリのautovacuum_max_workers倍が配分されるので、デフォルトの値をあまり高く設定しないよう注意してください。 別の設定項目autovacuum_work_memで制御するのが良いかもしれません。

Note that for the collection of dead tuple identifiers, <command>VACUUM</command> is only able to utilize up to a maximum of <literal>1GB</literal> of memory. 無効タプル識別子の集合に対しては、VACUUMは最大でも1GBまでしか使用することができないことに注意してください。

Specifies the maximum amount of memory to be used by each autovacuum worker process. If this value is specified without units, it is taken as kilobytes. It defaults to -1, indicating that the value of <xref linkend="guc-maintenance-work-mem"/> should be used instead. The setting has no effect on the behavior of <command>VACUUM</command> when run in other contexts. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 個々の自動バキュームワーカープロセスが使用する最大のメモリ量を指定します。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルトは-1で、maintenance_work_memが代わりに使われる設定になります。 別の文脈で実行されるVACUUMにはこの設定は影響しません。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

For the collection of dead tuple identifiers, autovacuum is only able to utilize up to a maximum of <literal>1GB</literal> of memory, so setting <varname>autovacuum_work_mem</varname> to a value higher than that has no effect on the number of dead tuples that autovacuum can collect while scanning a table. 無効タプル識別子の集合に対しては、自動バキュームは最大でも1GBまでしか使用することができません。 ですからautovacuum_work_memをそれ以上に指定しても、自動バキュームがテーブルを走査して収集できる無効タプルの数には影響を与えません。

Specifies the size of the <glossterm linkend="glossary-buffer-access-strategy">Buffer Access Strategy</glossterm> used by the <command>VACUUM</command> and <command>ANALYZE</command> commands. A setting of <literal>0</literal> will allow the operation to use any number of <varname>shared_buffers</varname>. Otherwise valid sizes range from <literal>128 kB</literal> to <literal>16 GB</literal>. If the specified size would exceed 1/8 the size of <varname>shared_buffers</varname>, the size is silently capped to that value. The default value is <literal>256 kB</literal>. If this value is specified without units, it is taken as kilobytes. This parameter can be set at any time. It can be overridden for <xref linkend="sql-vacuum"/> and <xref linkend="sql-analyze"/> when passing the <option>BUFFER_USAGE_LIMIT</option> option. Higher settings can allow <command>VACUUM</command> and <command>ANALYZE</command> to run more quickly, but having too large a setting may cause too many other useful pages to be evicted from shared buffers. VACUUMコマンドおよびANALYZEコマンドで使用されるバッファアクセスストラテジの大きさを指定します。 0を設定すると、それらの操作で任意の数のshared_buffersを使用できることになります。 それ以外の場合は、有効なサイズは128 kBから16 GBまでの範囲です。 指定されたサイズがshared_buffersのサイズの1/8を超える場合、サイズは黙ってその値に制限されます。 デフォルト値は256 kBです。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 このパラメータはいつでも設定できます。 このパラメータは、BUFFER_USAGE_LIMITオプションを渡すことによって、VACUUMおよびANALYZEに対して上書きできます。 設定を高くすると、VACUUMおよびANALYZEの実行速度が速くなりますが、設定を高くしすぎると、他の多くの有用なページが共有バッファから削除されてしまう可能性があります。

Specifies the maximum amount of memory to be used by logical decoding, before some of the decoded changes are written to local disk. This limits the amount of memory used by logical streaming replication connections. It defaults to 64 megabytes (<literal>64MB</literal>). Since each replication connection only uses a single buffer of this size, and an installation normally doesn't have many such connections concurrently (as limited by <varname>max_wal_senders</varname>), it's safe to set this value significantly higher than <varname>work_mem</varname>, reducing the amount of decoded changes written to disk. デコードされた更新がローカルディスクに書かれる前にロジカルデコーディングが使用する最大のメモリ量を指定します。 これにより、ロジカルストリーミングレプリケーションの接続が使用する最大メモリが制限されます。 デフォルトは64メガバイト(64MB)です。 個々のレプリケーション接続がここで指定した単一のバッファだけを使用し、インストールは通常たくさんの接続を並行して使わないので（max_wal_sendersで制限されます）、この値をwork_memよりもずっと大きくしても安全で、それによってデコードされた更新がディスクに書かれる量が削減されます。

Specifies the maximum safe depth of the server's execution stack. The ideal setting for this parameter is the actual stack size limit enforced by the kernel (as set by <literal>ulimit -s</literal> or local equivalent), less a safety margin of a megabyte or so. The safety margin is needed because the stack depth is not checked in every routine in the server, but only in key potentially-recursive routines. If this value is specified without units, it is taken as kilobytes. The default setting is two megabytes (<literal>2MB</literal>), which is conservatively small and unlikely to risk crashes. However, it might be too small to allow execution of complex functions. Only superusers and users with the appropriate <literal>SET</literal> privilege can change this setting. サーバの実行スタックの最大安全深度を指定します。 このパラメータの理想的な設定はカーネルにより強要される実際のスタック容量の（ulimit -sもしくはそれと同等の機能で設定された）限界から、1メガバイト程度の安全余裕度を差し引いたものです。 この安全余裕度は、サーバがすべてのルーチンではスタック深度を検査をせず、再帰を行う可能性のある重要なルーチンでのみ検査をするために必要となるものです。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 デフォルト設定は2メガバイト（2MB）で、かなり控え目、かつクラッシュの危険がなさそうな設定です。 しかし、複雑な関数の実行を許容するには小さ過ぎるかも知れません。 スーパーユーザと、適切なSET権限を持つユーザのみがこの設定を変更することができます。

Setting <varname>max_stack_depth</varname> higher than the actual kernel limit will mean that a runaway recursive function can crash an individual backend process. On platforms where <productname>PostgreSQL</productname> can determine the kernel limit, the server will not allow this variable to be set to an unsafe value. However, not all platforms provide the information, so caution is recommended in selecting a value. max_stack_depthを実際のカーネルの制限よりも高い値に設定した場合、暴走した再帰関数により、個々のバックエンドプロセスがクラッシュするかもしれません。 PostgreSQLがカーネルの制限を決定することができるプラットフォームでは、この変数を危険な値に設定させません。 しかし、すべてのプラットフォームがこの情報を提供できるわけではありません。 このため、値を選ぶ時には注意が必要です。

Specifies the shared memory implementation that the server should use for the main shared memory region that holds <productname>PostgreSQL</productname>'s shared buffers and other shared data. Possible values are <literal>mmap</literal> (for anonymous shared memory allocated using <function>mmap</function>), <literal>sysv</literal> (for System V shared memory allocated via <function>shmget</function>) and <literal>windows</literal> (for Windows shared memory). Not all values are supported on all platforms; the first supported option is the default for that platform. The use of the <literal>sysv</literal> option, which is not the default on any platform, is generally discouraged because it typically requires non-default kernel settings to allow for large allocations (see <xref linkend="sysvipc"/>). PostgreSQLの共有バッファおよび他の共有データを保持する主共有メモリ領域のためにサーバが使用すべき共有メモリの実装を指定します。 可能な値はmmap（mmapを使って獲得した無名共有メモリ）、sysv （shmgetを使って獲得したSystem V共有メモリ）、windows （Windows共有メモリ）です。 すべての値がすべてのプラットフォームでサポートされているわけではありません。 サポートされている最初のオプションがそのプラットフォームのデフォルトです。 どのプラットフォームでもデフォルトになっていないsysvオプションの利用は一般に推奨されません。 通常、デフォルトではないカーネルの設定が大きなアロケーションでは必要になるからです。 （19.4.1参照。）

Specifies the dynamic shared memory implementation that the server should use. Possible values are <literal>posix</literal> (for POSIX shared memory allocated using <literal>shm_open</literal>), <literal>sysv</literal> (for System V shared memory allocated via <literal>shmget</literal>), <literal>windows</literal> (for Windows shared memory), and <literal>mmap</literal> (to simulate shared memory using memory-mapped files stored in the data directory). Not all values are supported on all platforms; the first supported option is usually the default for that platform. The use of the <literal>mmap</literal> option, which is not the default on any platform, is generally discouraged because the operating system may write modified pages back to disk repeatedly, increasing system I/O load; however, it may be useful for debugging, when the <literal>pg_dynshmem</literal> directory is stored on a RAM disk, or when other shared memory facilities are not available. サーバが使う動的共有メモリの実装を指定します。可能な値はposix (shm_openで獲得するPOSIX共有メモリ)、sysv(shmgetで獲得するSystem V共有メモリ)、windows (Windows共有メモリ)、 mmap(データディレクトリ内のメモリマップファイルを使ってシミュレートする共有メモリ)です。 すべての値がすべてのプラットフォームでサポートされているわけではありません。 そのプラットフォームでの推奨実装が通常デフォルトになります。 どのプラットフォームでもデフォルトになっていないmmapは、オペレーティングシステムが変更されたページをディスクに継続的に書き込み、I/O負荷を増加させるので一般的には利用が推奨されていません。 しかし、デバッグ目的のためにpg_dynshmemディレクトリがRAMディスク上にある場合や、他の共有メモリ機能が使えない場合は有用かもしれません。

Specifies the amount of memory that should be allocated at server startup for use by parallel queries. When this memory region is insufficient or exhausted by concurrent queries, new parallel queries try to allocate extra shared memory temporarily from the operating system using the method configured with <varname>dynamic_shared_memory_type</varname>, which may be slower due to memory management overheads. Memory that is allocated at startup with <varname>min_dynamic_shared_memory</varname> is affected by the <varname>huge_pages</varname> setting on operating systems where that is supported, and may be more likely to benefit from larger pages on operating systems where that is managed automatically. The default value is <literal>0</literal> (none). This parameter can only be set at server start. サーバ起動時にパラレルクエリ用に獲得するメモリの量を指定します。 このメモリ領域不足していたり並列実行される問い合わせで使い尽くされると、新しいパラレルクエリはdynamic_shared_memory_typeで設定された方法でオペレーティングシステムから一時的に共有メモリを獲得しようとします。 これはメモリ管理のオーバーヘッドにより遅くなる可能性があります。 起動時にmin_dynamic_shared_memoryで獲得するメモリは、サポートするオペレーティングシステムに対するhuge_pagesの設定に影響を受けます。 huge pageを自動管理するオペレーティングシステム上でより大きなページにより恩恵を被る可能性が大きいです。 デフォルト値は0（none）です。 このパラメータはサーバ起動時にのみ設定可能です。

Specifies the maximum amount of disk space that a process can use for temporary files, such as sort and hash temporary files, or the storage file for a held cursor. A transaction attempting to exceed this limit will be canceled. If this value is specified without units, it is taken as kilobytes. <literal>-1</literal> (the default) means no limit. Only superusers and users with the appropriate <literal>SET</literal> privilege can change this setting. あるプロセスが一時ファイルとして使用できるディスクの最大容量を設定します。 例えば、ソートやハッシュの一時ファイルであったり、カーソルを保持する格納ファイルです。 この制限値を超えようとするトランザクションはキャンセルされます。 この値が単位なしで指定された場合は、キロバイト単位であるとみなします。 -1（デフォルトです）の場合は制限がありません。 この設定はスーパーユーザと、適切なSET権限を持つユーザのみ変更可能です。

This setting constrains the total space used at any instant by all temporary files used by a given <productname>PostgreSQL</productname> process. It should be noted that disk space used for explicit temporary tables, as opposed to temporary files used behind-the-scenes in query execution, does <emphasis>not</emphasis> count against this limit. この設定により、ある PostgreSQL セッションによって使用される一時ファイルの合計の容量が常に制約されることになります。 なお、問い合わせの実行において暗黙的に使用される一時ファイルとは異なり、一時テーブルとして明示的に使用されるディスク容量は、この制限には含まれません。

Sets the maximum number of simultaneously open files allowed to each server subprocess. The default is one thousand files. If the kernel is enforcing a safe per-process limit, you don't need to worry about this setting. But on some platforms (notably, most BSD systems), the kernel will allow individual processes to open many more files than the system can actually support if many processes all try to open that many files. If you find yourself seeing <quote>Too many open files</quote> failures, try reducing this setting. This parameter can only be set at server start. それぞれのサーバ子プロセスが同時にオープンできるファイル数の最大値をセットします。 デフォルトは1000ファイルです。 もしもカーネルがプロセス毎の安全制限を強要している場合、この設定を気にかける必要はありません。 しかし、いくつかのプラットフォーム（特にほとんどのBSDシステム）では、もし多くのプロセス全てがそれだけ多くのファイルを開くことを試みたとした場合、実際にサポートできるファイル数より多くのファイルを開くことを許しています。もしも「Too many open files」エラーが発生した場合、この設定を削減してみてください。 このパラメータはサーバ起動時にのみ設定可能です。

The amount of time that the process will sleep when the cost limit has been exceeded. If this value is specified without units, it is taken as milliseconds. The default value is zero, which disables the cost-based vacuum delay feature. Positive values enable cost-based vacuuming. コストの限度を越えた場合、プロセスがスリープする時間の長さです。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は0で、コストに基づいたvacuum遅延機能を無効にします。 正の整数はコストに基づいたvacuumを有効にします。

When using cost-based vacuuming, appropriate values for <varname>vacuum_cost_delay</varname> are usually quite small, perhaps less than 1 millisecond. While <varname>vacuum_cost_delay</varname> can be set to fractional-millisecond values, such delays may not be measured accurately on older platforms. On such platforms, increasing <command>VACUUM</command>'s throttled resource consumption above what you get at 1ms will require changing the other vacuum cost parameters. You should, nonetheless, keep <varname>vacuum_cost_delay</varname> as small as your platform will consistently measure; large delays are not helpful. コストに基づいたバキューム処理を使用する場合、vacuum_cost_delayの適切な値は通常かなり小さくなり、おそらく1ミリ秒以下になります。 バキュームによるリソース消費の調整は、他のバキュームのコストパラメータを変更して行うことが最善です。 vacuum_cost_delayを1ミリ秒以下に設定することは可能ですが、そうした遅延は古いプラットフォームでは正確には計測されないかも知れません。 そうしたプラットフォームでは、VACUUMのリソース消費制限を1ミリ秒のときに得られる値以上にするには、他のVACUUMコストパラメータの変更が必要となるでしょう。 とは言うものの、使用するプラットフォームで常に計測できる範囲でvacuum_cost_delayをできるだけ小さくするようにしてください。 大きな遅延は助けになりません。

The estimated cost for vacuuming a buffer found in the shared buffer cache. It represents the cost to lock the buffer pool, lookup the shared hash table and scan the content of the page. The default value is one. 共有バッファキャッシュの中のバッファにvacuumを掛ける予測コストです。バッファプールのロック、共有ハッシュテーブルの検索、およびページ内容走査のコストを示します。デフォルトの値は1です。

The estimated cost for vacuuming a buffer that has to be read from disk. This represents the effort to lock the buffer pool, lookup the shared hash table, read the desired block in from the disk and scan its content. The default value is 2. ディスクから読み込まれなければならないバッファにvacuumを掛ける予測コストです。これが示すものは、バッファプールロックの試み、共有ハッシュテーブルの参照、ディスクから目的ブロックの読み込み、そしてその内容走査です。デフォルトの値は2です。

The estimated cost charged when vacuum modifies a block that was previously clean. It represents the extra I/O required to flush the dirty block out to disk again. The default value is 20. vacuumが、先だって掃除したブロックを変更するのに必要な推定コストです。 ダーティブロックを再度ディスクにフラッシュするのに必要な余分なI/Oを表します。デフォルトの値は20です。

The accumulated cost that will cause the vacuuming process to sleep. The default value is 200. vacuumを掛けるプロセスをスリープさせることになる累計されたコストです。 デフォルトの値は200です。

Specifies the delay between activity rounds for the background writer. In each round the writer issues writes for some number of dirty buffers (controllable by the following parameters). It then sleeps for the length of <varname>bgwriter_delay</varname>, and repeats. When there are no dirty buffers in the buffer pool, though, it goes into a longer sleep regardless of <varname>bgwriter_delay</varname>. If this value is specified without units, it is taken as milliseconds. The default value is 200 milliseconds (<literal>200ms</literal>). Note that on many systems, the effective resolution of sleep delays is 10 milliseconds; setting <varname>bgwriter_delay</varname> to a value that is not a multiple of 10 might have the same results as setting it to the next higher multiple of 10. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. バックグラウンドライタの動作周期間の遅延を指定します。 それぞれの周期でライタは、（以下のパラメータで管理される）一部のダーティバッファの書き込みを行います。 そしてbgwriter_delayの長さスリープした後、これを繰りかえします。 しかし、バッファプールにダーティバッファが存在しない場合、bgwriter_delayに係わらずより長くスリープします。 この値が単位なしで指定された場合は、ミリ秒単位であるとみなします。 デフォルトの値は200ミリ秒（200ms）です。 多くのシステムで、スリープ遅延の実精度は10ミリ秒です。 bgwriter_delayの値の設定を10の倍数としない場合、次に大きい10の倍数に設定した結果と同一になるかもしれないことを覚えておいてください。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインで設定可能です。

In each round, no more than this many buffers will be written by the background writer. Setting this to zero disables background writing. (Note that checkpoints, which are managed by a separate, dedicated auxiliary process, are unaffected.) The default value is 100 buffers. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. それぞれの周期で、この数以上のバッファはバックグラウンドライタにより書き込まれません。 ゼロに設定することでバックグラウンド書き込みは無効になります。 （分離し、そして専用の補助プロセスにより管理されるチェックポイントは影響を受けません。） デフォルト値は100バッファです。 このパラメータはpostgresql.confファイル内、またはサーバのコマンドラインのみで設定可能です。

The number of dirty buffers written in each round is based on the number of new buffers that have been needed by server processes during recent rounds. The average recent need is multiplied by <varname>bgwriter_lru_multiplier</varname> to arrive at an estimate of the number of buffers that will be needed during the next round. Dirty buffers are written until there are that many clean, reusable buffers available. (However, no more than <varname>bgwriter_lru_maxpages</varname> buffers will be written per round.) Thus, a setting of 1.0 represents a <quote>just in time</quote> policy of writing exactly the number of buffers predicted to be needed. Larger values provide some cushion against spikes in demand, while smaller values intentionally leave writes to be done by server processes. The default is 2.0. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. 各周期で書き出されるダーティバッファ数は、最近の周期でサーバプロセスが必要とした新しいバッファ数を基にします。 次の周期で必要となるバッファ数を推定するために、最近必要とされた平均がbgwriter_lru_multiplierと掛け合わせられます。 ダーティバッファの書き出しは、同数の整理済み、再利用可能なバッファが利用できるようになるまで行われます。 （しかし1周期にbgwriter_lru_maxpagesを超えるバッファ数を書き出しません。） したがって、1.0と設定することは、必要と予想されるバッファ数の書き込みについて「必要なときに必要なだけ」というポリシーを表します。 より大きな値は突発的な要求に対する多少の緩衝材を提供します。 より小さな値はサーバプロセスでなされる書き込みを意図的に残します。 デフォルトは2.0です。 このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

Whenever more than this amount of data has been written by the background writer, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an <function>fsync</function> is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The valid range is between <literal>0</literal>, which disables forced writeback, and <literal>2MB</literal>. The default is <literal>512kB</literal> on Linux, <literal>0</literal> elsewhere. (If <symbol>BLCKSZ</symbol> is not 8kB, the default and maximum values scale proportionally to it.) This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. バックグラウンドライタがこの値より多く書く度に、OSが記憶装置に書き込むことを強制しようとします。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはOSがバックグラウンドでデータを大きな塊で書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な設定値は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は、Linuxでは512kBで、それ以外は0です。 (BLCKSZが8kBでなければ、この設定のデフォルト値と最大値がBLCKSZに比例して変更されます。) このパラメータはpostgresql.confファイル、または、サーバのコマンドラインでのみで設定可能です。

Whenever more than this amount of data has been written by a single backend, attempt to force the OS to issue these writes to the underlying storage. Doing so will limit the amount of dirty data in the kernel's page cache, reducing the likelihood of stalls when an <function>fsync</function> is issued at the end of a checkpoint, or when the OS writes data back in larger batches in the background. Often that will result in greatly reduced transaction latency, but there also are some cases, especially with workloads that are bigger than <xref linkend="guc-shared-buffers"/>, but smaller than the OS's page cache, where performance might degrade. This setting may have no effect on some platforms. If this value is specified without units, it is taken as blocks, that is <symbol>BLCKSZ</symbol> bytes, typically 8kB. The valid range is between <literal>0</literal>, which disables forced writeback, and <literal>2MB</literal>. The default is <literal>0</literal>, i.e., no forced writeback. (If <symbol>BLCKSZ</symbol> is not 8kB, the maximum value scales proportionally to it.) この量を超えるデータが単一のバックエンドによって書き込まれたときはいつでも、OSが記憶装置に書き込むことを強制します。 このことにより、カーネルのページキャッシュが持つダーティデータの量を一定量に制限し、チェックポイントの最後にfsyncが実行される際、あるいはバックグラウンドで実行される大きなバッチの中でOSがデータを書き出す際に性能の急激な低下を招く可能性を減らします。 多くの場合これによってトランザクションの遅延が大幅に少なくなりますが、あるケース、特にワークロードがshared_buffersよりも大きく、OSのページキャッシュよりも小さい時には性能が低下するかもしれません。 この設定が無効なプラットフォームがあります。 この値が単位なしで指定された場合は、ブロック単位であるとみなします。すなわち、BLCKSZバイト、一般的には8kBです。 有効な範囲は、この強制書き込み機能が無効になる0から、2MBまでです。 デフォルト値は0です(すなわち書き出し制御を行いません)。 (BLCKSZが8kBでなければ、最大値がBLCKSZに比例して変更されます。)

Sets the number of concurrent disk I/O operations that <productname>PostgreSQL</productname> expects can be executed simultaneously. Raising this value will increase the number of I/O operations that any individual <productname>PostgreSQL</productname> session attempts to initiate in parallel. The allowed range is 1 to 1000, or zero to disable issuance of asynchronous I/O requests. Currently, this setting only affects bitmap heap scans. PostgreSQLが同時実行可能であると想定する同時ディスクI/O操作の数を設定します。 この値を大きくすると、あらゆる個別のPostgreSQLセッションが並行して開始を試みるI/O操作の数が増加します。 設定可能な範囲は1から1000まで、または非同期I/Oリクエストの発行を無効にするゼロです。 現在、この設定はビットマップヒープスキャンのみに影響します。

For magnetic drives, a good starting point for this setting is the number of separate drives comprising a RAID 0 stripe or RAID 1 mirror being used for the database. (For RAID 5 the parity drive should not be counted.) However, if the database is often busy with multiple queries issued in concurrent sessions, lower values may be sufficient to keep the disk array busy. A value higher than needed to keep the disks busy will only result in extra CPU overhead. SSDs and other memory-based storage can often process many concurrent requests, so the best value might be in the hundreds. 磁気ディスクドライブにおいては、データベースに使用されるRAID 0ストライプ、RAID 1ミラーを構成する個々のドライブ数から始めると良いでしょう。（RAID 5ではパリティ用のドライブを数に含めません） しかし、同時実行セッションで発行される複数の問い合わせでデータベースが頻繁にビジーとなる場合、小さめの値で十分ディスクアレイがビジーになるかもしれません。 ディスクをビジーにするのに必要な値より大きな値を設定しても、余計なCPUオーバーヘッドを発生させるだけです。 SSDやそれ以外のメモリーベースの記憶装置は、多くの同時リクエストをこなすことができるので、最適な値は数百になるかもしれません。

Asynchronous I/O depends on an effective <function>posix_fadvise</function> function, which some operating systems lack. If the function is not present then setting this parameter to anything but zero will result in an error. On some operating systems (e.g., Solaris), the function is present but does not actually do anything. 非同期I/Oは実質的にposix_fadvise関数に依存します。 これは一部のオペレーティングシステムには存在しません。 この関数が存在しない場合、この値をゼロ以外に設定するとエラーとなります。 一部のオペレーティングシステム（例えばSolaris）では存在するけれども、実際何も行わないものもあります。

The default is 1 on supported systems, otherwise 0. This value can be overridden for tables in a particular tablespace by setting the tablespace parameter of the same name (see <xref linkend="sql-altertablespace"/>). デフォルトは、サポートされているシステムでは1、そうでなければ0です。 この値は、テーブルスペースパラメータの同じ名前のパラメータを設定することで、特定のテーブルスペース内のテーブルに対して上書きできます。 (ALTER TABLESPACEを参照ください)。

Similar to <varname>effective_io_concurrency</varname>, but used for maintenance work that is done on behalf of many client sessions. effective_io_concurrencyと似ていますが、多くのクライアントセッションのために行われる保守作業で適用されるところが異なります。

The default is 10 on supported systems, otherwise 0. This value can be overridden for tables in a particular tablespace by setting the tablespace parameter of the same name (see <xref linkend="sql-altertablespace"/>). サポートしているシステムではデフォルトは10で、それ以外は0です。 この値は同じ名前のテーブル空間パラメータを使って、特定のテーブル空間にあるテーブルのために置き換えることができます。（ALTER TABLESPACEを参照してください。）

Sets the maximum number of background processes that the system can support. This parameter can only be set at server start. The default is 8. システムがサポートするバックグラウンドプロセスの最大数を指定します。 このパラメータはサーバ起動時にのみ設定できます。 デフォルトは8です。

When running a standby server, you must set this parameter to the same or higher value than on the primary server. Otherwise, queries will not be allowed in the standby server. スタンバイサーバを起動しているときは、このパラメータを、プライマリサーバの設定値と同じかそれ以上にしなければなりません。 さもなければ、スタンバイサーバで問い合わせの実行ができなくなります。

When changing this value, consider also adjusting <xref linkend="guc-max-parallel-workers"/>, <xref linkend="guc-max-parallel-maintenance-workers"/>, and <xref linkend="guc-max-parallel-workers-per-gather"/>. この値を変更する際は、max_parallel_workers、max_parallel_maintenance_workers、max_parallel_workers_per_gatherを変更することも考慮してください。

Sets the maximum number of workers that can be started by a single <literal>Gather</literal> or <literal>Gather Merge</literal> node. Parallel workers are taken from the pool of processes established by <xref linkend="guc-max-worker-processes"/>, limited by <xref linkend="guc-max-parallel-workers"/>. Note that the requested number of workers may not actually be available at run time. If this occurs, the plan will run with fewer workers than expected, which may be inefficient. The default value is 2. Setting this value to 0 disables parallel query execution. 一つのGatherまたはGather Mergeノードに対して起動できるワーカー数の最大値を設定します。 パラレルワーカーは、max_parallel_workersで上限が決まるmax_worker_processesで確立されたプロセスのプールから取得されます。 実行時には、要求された数のワーカーは取得できないかもしれないことに注意してください。 そうなると、実行プランは期待していたよりも少ない数のワーカーで実行されることになり、効率は悪化するかもしれません。 デフォルト値は2です。 この設定値を0にすると、パラレルクエリの実行は行われません。

Note that parallel queries may consume very substantially more resources than non-parallel queries, because each worker process is a completely separate process which has roughly the same impact on the system as an additional user session. This should be taken into account when choosing a value for this setting, as well as when configuring other settings that control resource utilization, such as <xref linkend="guc-work-mem"/>. Resource limits such as <varname>work_mem</varname> are applied individually to each worker, which means the total utilization may be much higher across all processes than it would normally be for any single process. For example, a parallel query using 4 workers may use up to 5 times as much CPU time, memory, I/O bandwidth, and so forth as a query which uses no workers at all. パラレルクエリの実行により、パラレルクエリではない場合に比べて非常に多くのリソースが使用されるかもしれないことに注意してください。 これは、個々のワーカープロセスは完全に別個のプロセスであり、システムに対してユーザセッションが追加されたのと大体同じくらいの影響があるからです。 この設定値を選択する際には、他のリソースの消費量を制御する他の設定値、たとえばwork_memを設定するときと同様に、この点を考慮しておく必要があります。 work_memのような設定値によるリソース制限は、個々のワーカーに対して個別に適用されます。 つまり、ひとつのプロセスに対するよりも、すべてのプロセスの全体のリソース消費はずっと多いかもしれないということです。 たとえば、あるパラレルクエリが4つのワーカーを使っているとすると、ワーカーを使わない場合に比べて、最大5倍のCPU時間、メモリ、I/Oバンド幅、その他を使うかもしれません。

For more information on parallel query, see <xref linkend="parallel-query"/>. パラレルクエリに関する更なる情報については、第15章をご覧ください。

Sets the maximum number of parallel workers that can be started by a single utility command. Currently, the parallel utility commands that support the use of parallel workers are <command>CREATE INDEX</command> only when building a B-tree index, and <command>VACUUM</command> without <literal>FULL</literal> option. Parallel workers are taken from the pool of processes established by <xref linkend="guc-max-worker-processes"/>, limited by <xref linkend="guc-max-parallel-workers"/>. Note that the requested number of workers may not actually be available at run time. If this occurs, the utility operation will run with fewer workers than expected. The default value is 2. Setting this value to 0 disables the use of parallel workers by utility commands. 単一のユーティリティコマンドで使用されるパラレルワーカーの最大数を設定します。 今の所、パラレルワーカーの利用をサポートしているパラレルユーティリティコマンドは、CREATE INDEXがB-treeインデックスを構築するときと、FULLオプションなしのVACUUMです。 パラレルワーカーは、max_worker_processesで確立したプロセスのプールから取得され、max_parallel_workersによって制限されます。 要求したワーカー数は、実行時に実際には利用可能でないかも知れないことに注意してください。 この場合は、ユーティリティ操作は期待したよりも少ない数のワーカーにより実行されます。 デフォルト値は2です。 0に設定すると、ユーティリティコマンドはパラレルワーカーを使用しません。

Note that parallel utility commands should not consume substantially more memory than equivalent non-parallel operations. This strategy differs from that of parallel query, where resource limits generally apply per worker process. Parallel utility commands treat the resource limit <varname>maintenance_work_mem</varname> as a limit to be applied to the entire utility command, regardless of the number of parallel worker processes. However, parallel utility commands may still consume substantially more CPU resources and I/O bandwidth. パラレルユーティリティコマンドは同等の非パラレル操作よりもかなり多くのメモリを消費すべきでないことに留意してください。 この戦略は、一般的にワーカー毎にリソース制限を適用するパラレルクエリとは異なります。 パラレルワーカープロセスの数にかかわらず、パラレルユーティリティコマンドは、その全体でリソース制限maintenance_work_memが適用されるとみなします。 しかし、パラレルユーティリティコマンドは、依然としてかなり多くのCPUリソースとI/Oバンド幅を消費するかも知れません。

Sets the maximum number of workers that the system can support for parallel operations. The default value is 8. When increasing or decreasing this value, consider also adjusting <xref linkend="guc-max-parallel-maintenance-workers"/> and <xref linkend="guc-max-parallel-workers-per-gather"/>. Also, note that a setting for this value which is higher than <xref linkend="guc-max-worker-processes"/> will have no effect, since parallel workers are taken from the pool of worker processes established by that setting. パラレルクエリ操作用にシステムがサポートできる最大のワーカー数を設定します。 デフォルト値は8です。 この値を増減するときは、max_parallel_maintenance_workersとmax_parallel_workers_per_gatherを調整することを考慮してください。 また、この設定値をmax_worker_processesよりも高い値にしても効果がないことに注意してください。 max_worker_processesで決まるワーカープロセスのプールから、パラレルワーカーが使われるからです。

Allows the leader process to execute the query plan under <literal>Gather</literal> and <literal>Gather Merge</literal> nodes instead of waiting for worker processes. The default is <literal>on</literal>. Setting this value to <literal>off</literal> reduces the likelihood that workers will become blocked because the leader is not reading tuples fast enough, but requires the leader process to wait for worker processes to start up before the first tuples can be produced. The degree to which the leader can help or hinder performance depends on the plan type, number of workers and query duration. ワーカープロセスを待つ代わりに、GatherノードとGather Mergeノード配下の問い合わせプランをリーダープロセスが実行できるようにします。 デフォルトはonです。 この値をoffにすると、リーダーがタプルを十分早く読まないためにワーカーがブロックされる可能性を減らすことができますが、リーダープロセスは最初のタプルが生成される前にワーカープロセスが起動するのを待つ必要があります。 これがリーダーの性能を助けるのか、阻害要因になるかは計画型、ワーカーの数、問い合わせの実行時間の長さによります。

Sets the minimum amount of time that a query snapshot can be used without risk of a <quote>snapshot too old</quote> error occurring when using the snapshot. Data that has been dead for longer than this threshold is allowed to be vacuumed away. This can help prevent bloat in the face of snapshots which remain in use for a long time. To prevent incorrect results due to cleanup of data which would otherwise be visible to the snapshot, an error is generated when the snapshot is older than this threshold and the snapshot is used to read a page which has been modified since the snapshot was built. スナップショットを使用する際に、「snapshot too old」エラーが起こるリスク無しに問い合わせスナップショットが利用できる最小の期間を設定します。 この制限値を越えてデッド状態のままになったデータはバキュームしてしまうことが許可されます。 これにより、長い間残っていたスナップショットによりデータが溢れてしまうのを防ぐことができます。 スナップショットから見えるデータが消えることによる不正な結果を防ぐため、スナップショットがこの制限値よりも古く、かつこのスナップショットが作られた以降に変更されたページを読むためにスナップショットが使用されるときはエラーが発生します。

If this value is specified without units, it is taken as minutes. A value of <literal>-1</literal> (the default) disables this feature, effectively setting the snapshot age limit to infinity. This parameter can only be set at server start. この値が単位なしで指定された場合は、分単位であるとみなします。 -1（デフォルトです）を設定するとこの機能が無効になり、実質的にスナップショットの寿命を無限にします。 このパラメータはサーバ起動時にのみ設定可能です。

Useful values for production work probably range from a small number of hours to a few days. Small values (such as <literal>0</literal> or <literal>1min</literal>) are only allowed because they may sometimes be useful for testing. While a setting as high as <literal>60d</literal> is allowed, please note that in many workloads extreme bloat or transaction ID wraparound may occur in much shorter time frames. 実際の環境でのおすすめの値はおそらく数時間から2, 3日の間となるでしょう。 小さな値(たとえば0や1min)は、テストの際に有用だということで許可されています。 60dのような大きな値の設定もできますが、多くのワークロードにおいて、大きなデータ溢れやトランザクションIDの周回がそれよりはずっと短い期間で起こる可能性があることに注意してください。

When this feature is enabled, freed space at the end of a relation cannot be released to the operating system, since that could remove information needed to detect the <quote>snapshot too old</quote> condition. All space allocated to a relation remains associated with that relation for reuse only within that relation unless explicitly freed (for example, with <command>VACUUM FULL</command>). この機能が有効であると、リレーションの終端部にあるフリースペースはオペレーティングシステムには返却されません。 そうしないと、「snapshot too old」の条件の検出に必要な情報を削除してしまうことになるからです。 明示的に解放されない限り（たとえばVACUUM FULLによって）、リレーションに割り当てられた領域は、そのリレーションの中での再利用に限定して紐付けられます。

This setting does not attempt to guarantee that an error will be generated under any particular circumstances. In fact, if the correct results can be generated from (for example) a cursor which has materialized a result set, no error will be generated even if the underlying rows in the referenced table have been vacuumed away. Some tables cannot safely be vacuumed early, and so will not be affected by this setting, such as system catalogs. For such tables this setting will neither reduce bloat nor create a possibility of a <quote>snapshot too old</quote> error on scanning. この設定は、どのような状況でもエラーが検出されることを保証するものではありません。 （たとえば）マテリアライズされた結果集合を持つカーソルから正しい結果を得ることができるのであれば、たとえ参照している元のテーブルからVACUUMによって行が削除されたとしてもエラーにはなりません。 ある種のテーブルでは、早期にVACUUMできないので、この設定の影響を受けません。 例としては、システムカタログが挙げられます。 このようなテーブルにおいては、この設定によってデータ溢れを防ぐことも、スキャンの際に「snapshot too old」エラーを起こす可能性を作り出すこともできません。