Re: Overhauling GUCS
От | Steve Atkins |
---|---|
Тема | Re: Overhauling GUCS |
Дата | |
Msg-id | 448BD875-FE20-4985-92CD-DFF6FC0641D3@blighty.com обсуждение исходный текст |
Ответ на | Re: Overhauling GUCS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Overhauling GUCS
Re: Overhauling GUCS |
Список | pgsql-hackers |
On Jun 4, 2008, at 5:23 PM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Tom Lane wrote: >>> * Can we build a "configuration wizard" to tell newbies what >>> settings >>> they need to tweak? > >> That would trump all the other suggestions conclusively. Anyone >> good at >> expert systems? > > How far could we get with the answers to just three questions: > > * How many concurrent queries do you expect to have? > > * How much RAM space are you willing to let Postgres use? > > * How much "overhead" disk space are you willing to let Postgres use? > > concurrent queries drives max_connections, obviously, and RAM space > would drive shared_buffers and effective_cache_size, and both of them > would be needed to size work_mem. The third one is a bit weird but > I don't see any other good way to set the checkpoint parameters. > > If those aren't enough questions, what else must we ask? Or maybe > they > aren't the right questions at all --- maybe we should ask "is this a > dedicated machine or not" and try to extrapolate everything else from > what we (hopefully) can find out about the hardware. I'd be interested in putting together a framework+GUI client to do this cleanly in a cross-platform (Windows, Linux, Solaris, OS X as a bare minimum) sort of way, if no-one else already has such a thing. A framework doesn't get you all the way there, but it makes it a whole lot easier to work on what base data and information you need, and how easy it is to map pgsql-performance and #postgresql gut feel onto something more algorithmic. Cheers, Steve
В списке pgsql-hackers по дате отправления: