Re: Auto-tuning work_mem and maintenance_work_mem

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Peter Geoghegan <pg(at)heroku(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Date: 2013-10-10 11:28:13
Message-ID: CA+TgmoYv2vm_LV88A_y-ta43RA2K5sEv7ZotOzMZ64J6hU7Abg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 9, 2013 at 11:35 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> On Wed, Oct 9, 2013 at 8:20 PM, Bruce Momjian <bruce(at)momjian(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-10-10 11:28:55 Re: Auto-tuning work_mem and maintenance_work_mem
Previous Message Robert Haas 2013-10-10 11:16:47 Re: CommitFest progress