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+TgmoYv2vm_LV88A_y-ta43RA2K5sEv7ZotOzMZ64J6hU7Abg@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Peter Geoghegan <pg@heroku.com>)
Responses Re: Auto-tuning work_mem and maintenance_work_mem  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On Wed, Oct 9, 2013 at 11:35 PM, Peter Geoghegan <pg@heroku.com> wrote:
> On Wed, Oct 9, 2013 at 8:20 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> I am not sure that having that external to the backend really makes
>> sense because I am concerned people will not use it.  We can certainly
>> add it to change our defaults, of course.  Also consider many installs
>> are automated.
>
> Sure.
>
> I was imagining that we'd want to write the tool with the idea in mind
> that it was usually run immediately after initdb. We'd reach out to
> packagers to have them push it into the hands of users where that's
> practical.
>
> If you think that sounds odd, consider that on at least one popular
> Linux distro, installing MySQL will show a ncurses interface where the
> mysql password is set. We wouldn't need anything as fancy as that.

I actually had the thought that it might be something we'd integrate
*into* initdb.  So you'd do initdb --system-memory 8GB or something
like that and it would do the rest.  That'd be slick, at least IMHO.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: CommitFest progress
Next
From: Robert Haas
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem