Home Explore Blog CI



postgresql

86th chunk of `doc/src/sgml/config.sgml`
849d0aa03558ab062c7e3427753be76400ebaa3f95cdd7010000000100000fa3
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-partition-pruning" xreflabel="enable_partition_pruning">
      <term><varname>enable_partition_pruning</varname> (<type>boolean</type>)
       <indexterm>
        <primary><varname>enable_partition_pruning</varname> configuration parameter</primary>
       </indexterm>
      </term>
      <listitem>
       <para>
        Enables or disables the query planner's ability to eliminate a
        partitioned table's partitions from query plans.  This also controls
        the planner's ability to generate query plans which allow the query
        executor to remove (ignore) partitions during query execution.  The
        default is <literal>on</literal>.
        See <xref linkend="ddl-partition-pruning"/> for details.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-enable-partitionwise-join" xreflabel="enable_partitionwise_join">
      <term><varname>enable_partitionwise_join</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>enable_partitionwise_join</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Enables or disables the query planner's use of partitionwise join,
        which allows a join between partitioned tables to be performed by
        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.  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>

     <varlistentry id="guc-enable-partitionwise-aggregate" xreflabel="enable_partitionwise_aggregate">
      <term><varname>enable_partitionwise_aggregate</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>enable_partitionwise_aggregate</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Enables or disables the query planner's use of partitionwise grouping
        or aggregation, which allows grouping or aggregation on partitioned
        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.  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>

     <varlistentry id="guc-enable-presorted-aggregate" xreflabel="enable_presorted_aggregate">
      <term><varname>enable_presorted_aggregate</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>enable_presorted_aggregate</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Controls if the query planner will produce a plan which will provide
        rows which are presorted in the order required

Title: Query Planning Configuration: Partitionwise Operations and Presorted Aggregates
Summary
This section details boolean configuration parameters influencing the query planner. It focuses on `enable_partitionwise_join` (joining partitioned tables by matching partitions, requires matching partition keys and types, defaults to off due to increased memory and planning costs), `enable_partitionwise_aggregate` (grouping/aggregation on partitioned tables per partition, may require finalization, defaults to off due to memory and planning costs), and begins discussing `enable_presorted_aggregate`.