diff options
| author | David Rowley <drowley@postgresql.org> | 2024-08-01 01:27:20 +1200 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2024-08-01 01:27:20 +1200 |
| commit | 27146e79bf0301969945d73388f430fa8ff08870 (patch) | |
| tree | 10bb57940f0cd1bee68b3328bdccc6642ae84994 | |
| parent | 9744fe24118ba5738dda9008533ed00227f5d069 (diff) | |
| download | postgresql-27146e79bf0301969945d73388f430fa8ff08870.tar.gz postgresql-27146e79bf0301969945d73388f430fa8ff08870.zip | |
Doc: mention executor memory usage for enable_partitionwise* GUCs
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
| -rw-r--r-- | doc/src/sgml/config.sgml | 20 |
1 files changed, 14 insertions, 6 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 5cf34219188..c2538f3f8e4 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -5262,9 +5262,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> @@ -5282,9 +5286,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> |