Re: Auto-tuning work_mem and maintenance_work_mem
От | Stephen Frost |
---|---|
Тема | Re: Auto-tuning work_mem and maintenance_work_mem |
Дата | |
Msg-id | 20131010123120.GJ2706@tamriel.snowman.net обсуждение исходный текст |
Ответ на | Re: Auto-tuning work_mem and maintenance_work_mem (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
* Peter Geoghegan (pg@heroku.com) wrote: > On Wed, Oct 9, 2013 at 7:11 PM, Stephen Frost <sfrost@snowman.net> wrote: > > There is definitely something to be said for simplicity and just up'ing > > the default would have a more dramatic impact with a setting like > > work_mem than it would with shared_buffers, imv. > > Simplicity for us or for our users? My thinking was 'both', really. > I wonder if we should just ship something like pgtune (in /bin, not in > /contrib) that can be optionally used at initdb time. Making something > like wal_buffers self-tuning is really compelling, but work_mem is > quite different. I'm coming around to agree with this also- doing this at initdb time really makes more sense than during server start-up based on some (mostly) unrelated value. > I hear a lot of complaints about "the first 15 minutes experience" of > Postgres. It's easy to scoff at this kind of thing, but I think we > could do a lot better there, and at no real cost - the major blocker > to doing something like that has been fixed (of course, I refer to the > SysV shared memory limits). Is the person on a very small box where > our current very conservative defaults are appropriate? Why not ask a > few high-level questions like that to get inexperienced users started? There are certainly challenges here wrt asking questions during install, as was mentioned elsewhere, but I agree that we could do better. > The tool could even have a parameter that allows a packager to pass > total system memory without bothering the user with that, and without > bothering us with having to figure out a way to make that work > correctly and portably. Agreed. Thanks, Stephen
В списке pgsql-hackers по дате отправления: