mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Doc: mention executor memory usage for enable_partitionwise* GUCs

Browse Source 
Prior to this commit, the docs for enable_partitionwise_aggregate and
enable_partitionwise_join mentioned the additional overheads enabling
these causes for the query planner, but they mentioned nothing about the
possible surge in work_mem-consuming executor nodes that could end up in
the final plan.  Dimitrios reported the OOM killer intervened on his
query as a result of using enable_partitionwise_aggregate=on.

Here we adjust the docs to mention the possible increase in the number of
work_mem-consuming executor nodes that can appear in the final plan as a
result of enabling these GUCs.

Reported-by: Dimitrios Apostolou
Reviewed-by: Ashutosh Bapat
Discussion: https://postgr.es/m/3603c380-d094-136e-e333-610914fb3e80%40gmx.net
Discussion: https://postgr.es/m/CAApHDvoZ0_yqwPFEpb6h261L76BUpmh5GxBQq0LeRzQ5Jh3zzg@mail.gmail.com
Backpatch-through: 12, oldest supported version
This commit is contained in:
David Rowley 2024-08-01 01:27:54 +12:00
parent 924a08b76f
commit 51895d08b4
1 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
doc/src/sgml/config.sgml
View File

@ -5143,9 +5143,13 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
joining the matching partitions. Partitionwise join currently applies joining the matching partitions. Partitionwise join currently applies
only when the join conditions include all the partition keys, which only when the join conditions include all the partition keys, which
must be of the same data type and have one-to-one matching sets of must be of the same data type and have one-to-one matching sets of
child partitions. Because partitionwise join planning can use child partitions. With this setting enabled, the number of nodes
significantly more CPU time and memory during planning, the default is whose memory usage is restricted by <varname>work_mem</varname>
<literal>off</literal>. appearing in the final plan can increase linearly according to the
number of partitions being scanned. This can result in a large
increase in overall memory consumption during the execution of the
query. Query planning also becomes significantly more expensive in
terms of memory and CPU. The default value is <literal>off</literal>.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>
@ -5163,9 +5167,13 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
tables to be performed separately for each partition. If the tables to be performed separately for each partition. If the
<literal>GROUP BY</literal> clause does not include the partition <literal>GROUP BY</literal> clause does not include the partition
keys, only partial aggregation can be performed on a per-partition keys, only partial aggregation can be performed on a per-partition
basis, and finalization must be performed later. Because basis, and finalization must be performed later. With this setting
partitionwise grouping or aggregation can use significantly more CPU enabled, the number of nodes whose memory usage is restricted by
time and memory during planning, the default is <varname>work_mem</varname> appearing in the final plan can increase
linearly according to the number of partitions being scanned. This
can result in a large increase in overall memory consumption during
the execution of the query. Query planning also becomes significantly
more expensive in terms of memory and CPU. The default value is
<literal>off</literal>. <literal>off</literal>.
</para> </para>
</listitem> </listitem>