postgres.git / summary / log / commit / refs

commit    a459e583e06b640597c2e24ab6043a0701a5a545
Author:   David Rowley <drowley@postgresql.org>
Date:     Wed Jul 31 13:26:55 2024 +0000
First released in: 18.0, 12.20, 13.16, 14.13, 15.8, 16.4, 17.0

    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 3ef99e2ee08..e8c5d2a3b7f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -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>


[parent: 403cbd210819]