From: Peter Geoghegan <pg@bowt.ie>
Date: Tue, 28 Jul 2020 23:59:01 +0000 (-0700)
Subject: Doc: Remove obsolete CREATE AGGREGATE note.
X-Git-Tag: REL_14_BETA1~1911
X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=f36e82072c8866ba2eca08d88d1a5c3e0c3d1eb4;p=thirdparty%2Fpostgresql.git

Doc: Remove obsolete CREATE AGGREGATE note.

The planner is in fact willing to use hash aggregation when work_mem is
not set high enough for everything to fit in memory.  This has been the
case since commit 1f39bce0, which added disk-based hash aggregation.

There are a few remaining cases in which hash aggregation is avoided as
a matter of policy when the planner surmises that spilling will be
necessary.  For example, callers of choose_hashed_setop() still
conservatively avoid hash aggregation when spilling is anticipated.
That doesn't seem like a good enough reason to mention hash aggregation
in this context.

Backpatch: 13-, where disk-based hash aggregation was introduced.
---

diff --git a/doc/src/sgml/ref/create_aggregate.sgml b/doc/src/sgml/ref/create_aggregate.sgml
index 811e288ec1e..a315fff8bd3 100644
--- a/doc/src/sgml/ref/create_aggregate.sgml
+++ b/doc/src/sgml/ref/create_aggregate.sgml
@@ -386,10 +386,7 @@ SELECT col FROM tab ORDER BY col USING sortop LIMIT 1;
       If this parameter is omitted or is zero, a default estimate is used
       based on the <replaceable>state_data_type</replaceable>.
       The planner uses this value to estimate the memory required for a
-      grouped aggregate query.  The planner will consider using hash
-      aggregation for such a query only if the hash table is estimated to fit
-      in <xref linkend="guc-work-mem"/>; therefore, large values of this
-      parameter discourage use of hash aggregation.
+      grouped aggregate query.
      </para>
     </listitem>
    </varlistentry>