Re: Overhauling GUCS

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Smith <gsmith(at)gregsmith(dot)com>, Andreas Pflug <pgadmin(at)pse-consulting(dot)de>, "Decibel!" <decibel(at)decibel(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: Overhauling GUCS
Date: 2008-06-11 23:00:13
Message-ID: 200806112300.m5BN0Dc13952@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-06-11 23:14:35 Adding more context to tuptoaster's elog messages
Previous Message Greg Smith 2008-06-11 22:13:22 Re: How to Sponsor a Feature