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

From Robert Haas
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id CA+Tgmoaf4K4N8wo-yZjQwSAhbniZVugOhzv8Nn=ZHo8Cg41_YQ@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: Auto-tuning work_mem and maintenance_work_mem  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On Thu, Oct 17, 2013 at 12:03 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> On 10/17/2013 08:55 AM, Kevin Grittner wrote:
>> Robert Haas <robertmhaas@gmail.com> wrote:
>>
>>> I still think my previous proposal of increasing the defaults for
>>> work_mem and maintenance_work_mem by 4X would serve many more
>>> people well than it would serve poorly.  I haven't heard anyone
>>> disagree with that notion.  Does anyone disagree?  Should we do
>>> it?
>>
>>
>> I think that it makes sense to do that.  Those are still reasonable
>> defaults for a machine with 2GB of RAM, maybe even with less.
>> We're talking about putting this only in a release that will come
>> out in 2014.  How many machines used for a database server that new
>> will have less than that?
>
> A lot. A whole lot, more than what most people have in production with more
> than that. You are forgetting a very large segment of the population who
> run... VMs.

That's true, but are you actually arguing for keeping work_mem at 1MB?

Even on a VM with only 1GB of RAM, work_mem=4MB is not going to cause
any problems unless you're also trying to service a large number of
simultaneous connections.  And if you're doing that, you probably need
to rethink something anyway.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Next
From: Josh Berkus
Date:
Subject: Re: [PATCH] pg_sleep(interval)