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

From Magnus Hagander
Subject Re: Auto-tuning work_mem and maintenance_work_mem
Date
Msg-id CABUevEwkNOpexCGabp=mU2ZhpoiQ086iHEdeJqxEz+gfLcpKpw@mail.gmail.com
Whole thread Raw
In response to Re: Auto-tuning work_mem and maintenance_work_mem  (Peter Geoghegan <pg@heroku.com>)
List pgsql-hackers
On Thu, Oct 10, 2013 at 5:35 AM, 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.

That's a packaging feature though, and not a MySQL feature. And of
course, on other platforms, popping up somethjing like that is
explicitly *forbidden* by the packaging standards.

But it shows an important distinction - we really only need to provide
an *infrastructure* that can be used on all platforms. The platform
specific interfaces to it can go in the packaging.

(And yes, in a lot of cases "we" are also the packagers, but the point
being that this code is already 100% platform specific, making the
problem easier)

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Auto-tuning work_mem and maintenance_work_mem
Next
From: Ronan Dunklau
Date:
Subject: Re: Triggers on foreign tables