database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-11-03 09:13:20 +03:00
Code 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:26:55 +12:00
parent 403cbd2108
commit a459e583e0
1 changed files with 14 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -5374,9 +5374,13 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
joining the matching partitions. Partitionwise join currently applies
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
child partitions. Because partitionwise join planning can use
significantly more CPU time and memory during planning, the default is
<literal>off</literal>.
child partitions. With this setting enabled, the number of nodes
whose memory usage is restricted by <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>.
</para>
</listitem>
</varlistentry>
@@ -5394,9 +5398,13 @@ ANY <replaceable class="parameter">num_sync</replaceable> ( <replaceable class="
tables to be performed separately for each partition. If the
<literal>GROUP BY</literal> clause does not include the partition
keys, only partial aggregation can be performed on a per-partition
basis, and finalization must be performed later. Because
partitionwise grouping or aggregation can use significantly more CPU
time and memory during planning, the default is
basis, and finalization must be performed later. With this setting
enabled, the number of nodes whose memory usage is restricted by
<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>.
</para>
</listitem>