| タイプ: | integer |
| デフォルト: | 4096 (4MB) |
| 分: | 64 (64kB) |
| 最大: | 2147483647 (2147483647kB) |
| 単位: | KB |
| コンテキスト: | user |
| 再起動: | false |
一時ディスクファイルに書き込むようになる前に、クエリ操作（たとえば並べ替えとハッシュテーブル操作）が使用する最大のメモリ容量を指定します。この値が単位なしで指定された場合は、キロバイト単位であるとみなします。デフォルト値は4メガバイト（4MB）です。複雑な問い合わせの場合、いくつかの並び替えもしくはハッシュ操作が並行して実行されることに注意してください。それぞれの操作による一時メモリへの書き込み開始の前に、この値が指定するのと同じメモリ容量の使用をそれらの操作に許容します。さらに、いくつかの実行中のセッションはこれらの動作を同時に行います。したがって、使用されるメモリの合計は、work_memの数倍になります。値を選択する時には、この事実に留意することが必要です。並び替え操作はORDER BY、DISTINCT、およびマージ結合に対して使われます。ハッシュテーブルはハッシュ結合、ハッシュに基づいた集約、およびIN副問い合わせのハッシュに基づいた処理で使用されます。
推奨事項 [EN]
Sets the limit for the amount of non-shared RAM available for each query operation, including sorts and hashes. This limit acts as a primitive resource control, preventing the server from going into swap due to overallocation. Note that this is non-shared RAM per operation, which means large complex queries can use multple times this amount. Also, work_mem is allocated by powers of two, so round to the nearest binary step. The second formula is for reporting and DW servers which run a lot of complex queries.
On StackOverflow
On pgsql-hackers
- Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators
- Should work_mem be stable for a prepared statement?
- Re: Add the ability to limit the amount of memory that can be allocated to backends.
- Re: Increase of maintenance_work_mem limit in 64-bit Windows
- Re: Proposal: "query_work_mem" GUC, to distribute working memory to the query's individual operators