Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 5f567b3

Browse files
committed
doc: clarify the effect of concurrent work_mem allocations
Reported-by: Sami Imseih Discussion: https://postgr.es/m/66590882-F48C-4A25-83E3-73792CF8C51F@amazon.com Backpatch-through: 11
1 parent eec2190 commit 5f567b3

File tree

1 file changed

+5
-4
lines changed

1 file changed

+5
-4
lines changed

doc/src/sgml/config.sgml

Lines changed: 5 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1834,9 +1834,10 @@ include_dir 'conf.d'
18341834
(such as a sort or hash table) before writing to temporary disk files.
18351835
If this value is specified without units, it is taken as kilobytes.
18361836
The default value is four megabytes (<literal>4MB</literal>).
1837-
Note that for a complex query, several sort or hash operations might be
1838-
running in parallel; each operation will generally be allowed
1839-
to use as much memory as this value specifies before it starts
1837+
Note that a complex query might perform several sort and hash
1838+
operations at the same time, with each operation generally being
1839+
allowed to use as much memory as this value specifies before
1840+
it starts
18401841
to write data into temporary files. Also, several running
18411842
sessions could be doing such operations concurrently.
18421843
Therefore, the total memory used could be many times the value
@@ -1850,7 +1851,7 @@ include_dir 'conf.d'
18501851
<para>
18511852
Hash-based operations are generally more sensitive to memory
18521853
availability than equivalent sort-based operations. The
1853-
memory available for hash tables is computed by multiplying
1854+
memory limit for a hash table is computed by multiplying
18541855
<varname>work_mem</varname> by
18551856
<varname>hash_mem_multiplier</varname>. This makes it
18561857
possible for hash-based operations to use an amount of memory

0 commit comments

Comments
 (0)