diff options
| author | David Rowley <drowley@postgresql.org> | 2024-08-01 01:25:25 +1200 |
|---|---|---|
| committer | David Rowley <drowley@postgresql.org> | 2024-08-01 01:25:25 +1200 |
| commit | 057ee9183c2142f6ecd9035aa6b96c5509c18a27 (patch) | |
| tree | c103a565e01ab3fbfc2757c670af642ede5b9879 /doc/src | |
| parent | e54a42ac9d49ef9cd660d1bf55f09c88bb841ee9 (diff) | |
| download | postgresql-057ee9183c2142f6ecd9035aa6b96c5509c18a27.tar.gz postgresql-057ee9183c2142f6ecd9035aa6b96c5509c18a27.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
Diffstat (limited to 'doc/src')
| -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 57cd7bb9727..4e77adc7f17 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -5567,9 +5567,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> @@ -5587,9 +5591,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> |