From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Default setting for enable_hashagg_disk |
Date: | 2020-07-13 12:16:45 |
Message-ID: | CAApHDvpQ91e2ty1_C8o0PsEyPTA+WGZZcC=R0H9CPE3s2HW2hg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Mon, 13 Jul 2020 at 23:51, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Naresh gandi | 2020-07-13 12:20:51 | Re: Additional Chapter for Tutorial |
Previous Message | Peter Eisentraut | 2020-07-13 11:51:42 | Re: Default setting for enable_hashagg_disk |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2020-07-13 12:18:24 | Re: Don't choke on files that are removed while pg_rewind runs. |
Previous Message | wenjing zeng | 2020-07-13 11:59:24 | Re: [Proposal] Global temporary tables |