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+TgmoYzis4DuXAggnJCEM8=kHZcVr05stm+DFCbaVskt4Ow0g@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Auto-tuning work_mem and maintenance_work_mem  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Oct 9, 2013 at 2:28 PM, Bruce Momjian <bruce@momjian.us> wrote:
> On Wed, Oct  9, 2013 at 01:49:23PM -0400, Robert Haas wrote:
>> > Having really bad defaults so everyone knows they are bad really isn't
>> > user-friendly because the only people who know they are really bad are
>> > the people who are tuning them already.  Again, we need to think of the
>> > typical user, not us.
>>
>> I think a typical user will be happier if we simply raise the default
>> rather than stick in an auto-tuning formula that's largely wishful
>> thinking.  You're welcome to disagree, but you neither quoted nor
>> responded to my points about the sorts of scenarios in which that
>> might cause surprising and hard-to-debug results.
>
> Well, pointing out that is will be negative for some users (which I
> agree) doesn't refute that it will be better for most users.

That is, of course, true.  But I don't think you've made any argument
that the pros exceed the cons, or that the formula will in general be
accurate.  It's massive simpler than what Josh says he uses, for
example, and he's not making the completely silly assumption that
available RAM is 4 * shared_buffers.  An auto-tuning formula that's
completely inaccurate probably won't be better for most users.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Review: Patch to compute Max LSN of Data Pages
Next
From: Kevin Grittner
Date:
Subject: Re: Pattern matching operators a index