Re: Auto-tuning work_mem and maintenance_work_mem - Mailing list pgsql-hackers

From Claudio Freire
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id CAGTBQpaX7RtWk=-TRUB-jMk1tppoxdDtR7i5xu209q=xWw0AMw@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Oct 16, 2013 at 5:30 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Oct 16, 2013 at 04:25:37PM -0400, Andrew Dunstan wrote:
>>
>> On 10/09/2013 11:06 AM, Andrew Dunstan wrote:
>> >
>> >
>> >
>> >The assumption that each connection won't use lots of work_mem is
>> >also false, I think, especially in these days of connection
>> >poolers.
>> >
>> >
>>
>>
>> Andres has just been politely pointing out to me that my knowledge
>> of memory allocators is a little out of date (i.e. by a decade or
>> two), and that this memory is not in fact likely to be held for a
>> long time, at least on most modern systems. That undermines
>> completely my reasoning above.
>>
>> Given that, it probably makes sense for us to be rather more liberal
>> in setting work_mem that I was suggesting.
>
> Ah, yes, this came up last year (MMAP_THRESHOLD):
>
>         http://www.postgresql.org/message-id/20120730161416.GB10877@momjian.us


Beware of depending on that threshold. It varies wildly among platforms.

I've seen implementations with the threshold well above 64MB.



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: better atomics
Next
From: Andres Freund
Date:
Subject: Re: better atomics