Re: Overhauling GUCS

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Overhauling GUCS
Дата
Msg-id 200806112300.m5BN0Dc13952@momjian.us
обсуждение исходный текст
Ответ на Re: Overhauling GUCS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Overhauling GUCS
Список pgsql-hackers
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.

Having returned from Japan, I read through this thread.  It had lots of
ideas (new format for postgresql.conf, more/less comments in
postgresql.conf) but I didn't see any of the ideas getting a majority.

I think we do a good job of making many settings automatic (meaning no
one even sees them), but we don't to a great job of making the visible
settings easy to set, both in the process (no GUI) and in knowing the
proper value.

There are two ideas I did think had merit.  First, using ## for
system-supplied comments, so user comments would be easier to identify.
There might be value in doing that even if it were not helpful for
scripts.

The second idea is the idea of having one parameter depend on another. 
Not only could we do that for some of our existing parameters, but we
could have pseudo-parameters like concurrent_queries, memory_usage, and
extra_disk_space that could be at the top of postgresql.conf and then
affect the other settings.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Greg Smith
Дата:
Сообщение: Re: How to Sponsor a Feature
Следующее
От: Tom Lane
Дата:
Сообщение: Adding more context to tuptoaster's elog messages