From e362f469c50f6e671285640cc2087345ab55a9b2 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Tue, 28 Jul 2020 16:58:59 -0700 Subject: [PATCH] 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. --- doc/src/sgml/ref/create_aggregate.sgml | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) 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 state_data_type. 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 ; therefore, large values of this - parameter discourage use of hash aggregation. + grouped aggregate query.