postgres.git / summary / log / commit / refs

commit    51895d08b41a5e5ed7e7a477fb5aa36213347ea7
Author:   David Rowley <drowley@postgresql.org>
Date:     Wed Jul 31 13:27:54 2024 +0000

    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


 doc/src/sgml/config.sgml | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index f3a5e82d8cb..efc039b5d26 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -5143,9 +5143,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>
@@ -5163,9 +5167,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>


[parent: 924a08b76f5d]