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.
This commit is contained in:
parent
a57c837e5c
commit
e362f469c5
|
@ -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>
|
||||
|
|
Loading…
Reference in New Issue