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

From Andres Freund
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id 20131009190755.GC3825719@alap2.anarazel.de
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  ("Joshua D. Drake" <jd@commandprompt.com>)
List pgsql-hackers
On 2013-10-09 10:02:12 -0700, Joshua D. Drake wrote:
> 
> On 10/09/2013 07:58 AM, Bruce Momjian wrote:
> 
> >>But it still is an independent parameter.  I am just changing the default.
> >>
> >>>maintenance_work_mem can depend on work_mem ~ work_mem * 1 * max_connection / 4
> >>
> >>That is kind of hard to do because we would have to figure out if the
> >>old maintenance_work_mem was set from a default computation or by the
> >>user.
> >
> >FYI, this auto-tuning is not for us, who understand the parameters and
> >how they interact, but for the 90% of our users who would benefit from
> >better defaults.  It is true that there might now be cases where you
> >would need to _reduce_ work_mem from its default, but I think the new
> >computed default will be better for most users.
> >
> 
> Just to step in here as a consultant. Bruce is right on here. Autotuning has
> nothing to do with us, it has to do with Rails developers who deploy
> PostgreSQL and known nothing of it except what ActiveRecord tells them (I am
> not being rude here).

But rails environments aren't exactly a good case for this. They often
have a high number of connection that's even pooled. They also mostly
don't have that many analytics queries where a high work_mem benefits
them much.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Backup throttling
Next
From: Robert Haas
Date:
Subject: Re: Patch: FORCE_NULL option for copy COPY in CSV mode