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 exactly 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>.
+ 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>
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>