Horton

Re: Default setting for enable_hashagg_disk

David Rowley <dgrowleyml@gmail.com>

View thread View on postgr.es
From: David Rowley <dgrowleyml@gmail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Jeff Davis <pgsql@j-davis.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-07-13T12:16:45Z
Lists: pgsql-hackers, pgsql-docs 
On Mon, 13 Jul 2020 at 23:51, Peter Eisentraut
<peter.eisentraut@2ndquadrant.com> wrote:
> I have an anecdote that might be related to this discussion.
>
> I was running an unrelated benchmark suite.  With PostgreSQL 12, one
> query ran out of memory.  With PostgreSQL 13, the same query instead ran
> out of disk space.  I bisected this to the introduction of disk-based
> hash aggregation.  Of course, the very point of that feature is to
> eliminate the out of memory and make use of disk space instead.  But
> running out of disk space is likely to be a worse experience than
> running out of memory.  Also, while it's relatively easy to limit memory
> use both in PostgreSQL and in the kernel, it is difficult or impossible
> to limit disk space use in a similar way.

Isn't that what temp_file_limit is for?

David

Commits

  1. Add hash_mem_multiplier GUC.

  2. HashAgg: use better cardinality estimate for recursive spilling.

  3. Remove hashagg_avoid_disk_plan GUC.

  4. Doc fixup for hashagg_avoid_disk_plan GUC.

  5. Rework HashAgg GUCs.

  6. Disk-based Hash Aggregation.

  7. Implement partition-wise grouping/aggregation.

  8. Defer creation of partially-grouped relation until it's needed.