From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sort performance cliff with small work_mem |
Date: | 2018-05-02 16:41:35 |
Message-ID: | 29063.1525279295@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Wed, May 2, 2018 at 11:38 AM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> To fix, I propose that we change the above so that we always subtract
>> tapeSpace, but if there is less than e.g. 32 kB of memory left after that
>> (including, if it went below 0), then we bump availMem back up to 32 kB. So
>> we'd always reserve 32 kB to hold the tuples, even if that means that we
>> exceed 'work_mem' slightly.
> Sounds very reasonable.
Agreed. I think that was my code to start with, and the issue certainly
didn't occur to me at the time.
I don't like the idea of using hardwired "32kB" though; some multiple
of TAPE_BUFFER_OVERHEAD seems more plausible. Perhaps MINORDER times
TAPE_BUFFER_OVERHEAD would be good?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?= | 2018-05-02 16:41:38 | Re: Transform for pl/perl |
Previous Message | Tom Lane | 2018-05-02 16:30:29 | Re: Is there a memory leak in commit 8561e48? |