Overhauling GUCS

On Fri, 30 May 2008, Josh Berkus wrote:

1) Add several pieces of extra information to guc.c in the form of extra
"gettext" commands: default value, subcategory, long description,
recommendations, enum lists.
2) Incorporate this data into pg_settings

When you last brought this up in February (I started on a long reply to
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00759.php that I
never quite finished) the thing I got stuck on was how to deal with the
way people tend to comment in these files as they change things.

One problem I didn't really see addressed by the improvements you're
suggesting is how to handle migrating customized settings to a new version
(I'm talking about 8.4->9.0 after this is in place, 8.3->8.4 is a whole
different problem). It would be nice to preserve "history" of what people
did like in your examples (which look exactly like what I find myself
running into in the field). Now, that will get a lot easier just by
virtue of having a smaller config file, but I think that adding something
into pg_settings that allows saving user-added commentary would be a nice
step toward some useful standardization on that side of things. It would
make future automated tools aimed at parsing and generating new files, as
part of things like version upgrades, a lot easier if there was a standard
way such comments were handled in addition to the raw data itself.

The other thing I'd like to see make its way into pg_settings, so that
tools can operate on it just by querying the database, is noting what file
the setting came from so that you can track things like include file
usage. I think with those two additions (comments and source file
tracking) it would even be concievable to clone a working facsimile of
even a complicated postgresql.conf file set remotely just by reading
pg_settings.

While a bit outside of the part you're specifically aiming to improve
here, if you could slip these two additions in I think it would be a boon
to future writers of multi-server management tools as well.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

On Fri, 2008-05-30 at 17:34 -0700, Josh Berkus wrote:

There's obviously some refinements needed, but what do people think of
the above general idea?

My initial reaction is that this is too much change, though I agree with
many of the points and understand it is well intended.

We have many supporters, though 90% of them seldom touch the database
from one release to the next. Many are dismayed that every time they do
we've fiddled with the knobs so some don't work anymore, some are
missing or renamed and there's a few new ones. So if they don't know
what they're doing it is frequently because we keep moving the
goalposts.

We should also consider that most people with multiple databases are
running multiple versions of PostgreSQL. The main reason for that is
that we keep changing the behaviour of SQL between releases, so even if
you had a magic superfast upgrade utility, in perhaps 50% of cases they
won't use it because they have to do a full application re-test, which
costs time and money.

Trying to be a Postgres DBA is hard when each new release is configured
differently to the last one and we have a major release about 3-5 more
frequently than Oracle/SQLServer. That is probably largest source of
questions and annoyance from the students on the courses I run.

So my viewpoint is that we should be aggressively adding new features,
yet be conservative in changing existing behaviour: provide options for
behaves-like-previous-release and keep the administrative interfaces as
similar as possible between releases.

If you wish to make changes, I would suggest that you simply reorder
some of the parameters in the .conf file, so that the ones you think are
important are grouped at the top.

Another suggestion would be to allow a #include style interface within
postgresql.conf. We can then do this:

#include standard_postgresql.conf

# now we put Josh's favourite GUCs as overrides on the above
...

That keeps things simple because the standard_postgresql.conf looks
almost identical to what people are used to. It also provides a new
feature, allowing people to include site-wide defaults for various
settings to allow easy implementation of local policy. It also
demonstrates a best practice approach to managing GUCs.

Some other problems I see with GUCs

* It's not possible to set one parameter depending upon the setting of
another.

* It's always unclear which GUCs can be changed, and when. That is much
more infrequently understood than the meaning of them.

* We should rename effective_cache_size to something that doesn't sound
like it does what shared_buffers does

* There is no config verification utility, so if you make a change and
then try to restart and it won't, you are in trouble.

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support

Simon Riggs wrote:

On Fri, 2008-05-30 at 17:34 -0700, Josh Berkus wrote:

We have many supporters, though 90% of them seldom touch the database
from one release to the next. Many are dismayed that every time they do
we've fiddled with the knobs so some don't work anymore, some are
missing or renamed and there's a few new ones.

I certainly agree we don't want to make it more difficult.

So if they don't know
what they're doing it is frequently because we keep moving the
goalposts.

No, its because they don't read the docs. We are not talking about
dumping SQL here :) I don't feel it is correct to not perform such a
needed cleanup for fear that some user can't be bothered to read the
documentation.

We should also consider that most people with multiple databases are
running multiple versions of PostgreSQL. The main reason for that is
that we keep changing the behaviour of SQL between releases, so even if
you had a magic superfast upgrade utility, in perhaps 50% of cases they
won't use it because they have to do a full application re-test, which
costs time and money.

This could certainly be a problem.

Trying to be a Postgres DBA is hard when each new release is configured
differently to the last one and we have a major release about 3-5 more
frequently than Oracle/SQLServer. That is probably largest source of
questions and annoyance from the students on the courses I run.

That is the nature of the beast though. We are still learning,
improving, engineering. It's part of progress of the database. I would
suggest that your students (which is what I tell mine) not upgrade every
release but instead try hanging out for 3 years per release.

So my viewpoint is that we should be aggressively adding new features,
yet be conservative in changing existing behaviour: provide options for
behaves-like-previous-release and keep the administrative interfaces as
similar as possible between releases.

I agree with this in principle but not on this argument.

If you wish to make changes, I would suggest that you simply reorder
some of the parameters in the .conf file, so that the ones you think are
important are grouped at the top.

IMO, the only settings that should be in the postgresql.conf are the
ones that require a restart. The rest should be gathered from pg_settings.

Another suggestion would be to allow a #include style interface within
postgresql.conf. We can then do this:

#include standard_postgresql.conf

# now we put Josh's favourite GUCs as overrides on the above
...

I think that could get very messy but Apache allows this. It isn't
exactly a new idea and I wouldn't fight against it.

Some other problems I see with GUCs

* It's not possible to set one parameter depending upon the setting of
another.

That is getting a bit more complicated than I think we need. Unless I am
misunderstanding what you are saying.

* It's always unclear which GUCs can be changed, and when. That is much
more infrequently understood than the meaning of them.

This is a definite problem. Even the docs are a bit difficult on this
one. It should be a nice simple grid :) or like I said above, only goes
in the conf if requires a restart.

Hmm,

SET effective_cache_size = '5000MB';
WARNING: You must issue a reload to the database for this to take effect.

* We should rename effective_cache_size to something that doesn't sound
like it does what shared_buffers does

Hmmm, I wonder if it is not the other way around. Although I know that
one thing I run into is that a lot of people think effective_cache is an
allocation.

shared_buffer_alloc?
shared_mem?

* There is no config verification utility, so if you make a change and
then try to restart and it won't, you are in trouble.

+1 +1

Sincerely,

Joshua D. Drake

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Many are dismayed that every time they do we've fiddled with the
knobs so some don't work anymore, some are missing or renamed and
there's a few new ones.

...

* We should rename effective_cache_size

*raises eyebrow*

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200805311114
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhBa3UACgkQvJuQZxSWSsg6pACgu2EJOyzj+ik79QwzdTTfi8Qj
aW0AoNayz4sniFVFxnQFgnxh7dPB6QOD
=Uyap
-----END PGP SIGNATURE-----

Josh Berkus <josh@agliodbs.com> writes:

Currently, PostgreSQL,conf and our set of GUC configurations suffer from
4 large problems:

1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options, the
vast majority of which most users will never touch.
3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the settings.sgml), which are only synched with each other manually.
4. We don't seem to be getting any closer to autotuning.

The proposal doesn't actually solve any of those problems.

Here's a list of the things we want to change. It's all a package and
should make sense if you take all the changes as a whole.

1) Add several pieces of extra information to guc.c in the form of extra
"gettext" commands: default value, subcategory, long description,
recommendations, enum lists.
2) Incorporate this data into pg_settings
3) Delete postgresql.conf.sample
4) Add a script called pg_generate_conf to generate a postgresql.conf
based on guc.c and command-line switches (rather than
postgresql.conf.sample), which would be called automatically by initdb.

I disagree with doing any of this. It doesn't result in any useful
reduction in maintenance effort, and what it does do is make it
impossible to keep control over the detailed layout, formatting,
commenting etc in a sample postgresql.conf. Nor do I think that
"generate a whole config file from scratch" is going to be a useful
behavior for tuning problems --- how will you merge it with what
you had before?

regards, tom lane

On May 31, 2008, at 09:23, Tom Lane wrote:

1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options,
the
vast majority of which most users will never touch.
3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the settings.sgml), which are only synched with each other
manually.
4. We don't seem to be getting any closer to autotuning.

The proposal doesn't actually solve any of those problems.

It solves #2 at least.

I disagree with doing any of this. It doesn't result in any useful
reduction in maintenance effort, and what it does do is make it
impossible to keep control over the detailed layout, formatting,
commenting etc in a sample postgresql.conf. Nor do I think that
"generate a whole config file from scratch" is going to be a useful
behavior for tuning problems --- how will you merge it with what
you had before?

I'd love to see these issues resolved. The current postgresql.conf is
way over the top. Might you have a better idea?

Thanks,

David

Simon, Tom, Greg,

Now, that will get a lot easier just by
virtue of having a smaller config file, but I think that adding something
into pg_settings that allows saving user-added commentary would be a nice
step toward some useful standardization on that side of things. It would
make future automated tools aimed at parsing and generating new files, as
part of things like version upgrades, a lot easier if there was a standard
way such comments were handled in addition to the raw data itself.

Hmmm. What about a COMMENT ON SETTING? That seems like it would serve the
purpose ... and make preserving user comments easier than the current
file-conversion approach.

The other thing I'd like to see make its way into pg_settings, so that
tools can operate on it just by querying the database, is noting what file
the setting came from so that you can track things like include file
usage. I think with those two additions (comments and source file
tracking) it would even be concievable to clone a working facsimile of
even a complicated postgresql.conf file set remotely just by reading
pg_settings.

Hmmm. Any idea how to do this? It sounds like a good idea to me.

So my viewpoint is that we should be aggressively adding new features,
yet be conservative in changing existing behaviour: provide options for
behaves-like-previous-release and keep the administrative interfaces as
similar as possible between releases.

It's my viewpoint based on a lot of user feedback that the current
postgresql.conf is fundamentally broken and a major roadblock to PostgreSQL
adoption. This was a point with which there was pretty much universal
agreement when I talked with people at pgCon. That is, I beleive that you're
arguing for keeping .conf stable for the 5% of users who understand it and
ignoring the 95% of users who are baffled by it.

At this point, I think we are the only major SQL database without some form of
basic autotuning for the most significant settings (certainly MySQL, Oracle,
and SQL Server have it); we've been able to coast through that because
autotuning features are new in other DBs, but it's going to start to hurt us
pretty soon.

Now, I do believe that we should plan any GUCS overhaul to happen in one
postgresql version rather than phasing it in over multiple versions so that
administrators only need to get used to a new way once.

Currently, PostgreSQL,conf and our set of GUC configurations suffer from
4 large problems:

1. Most people have no idea how to set these.
2. The current postgresql.conf file is a huge mess of 194 options, the
vast majority of which most users will never touch.
3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the settings.sgml), which are only synched with each other manually.
4. We don't seem to be getting any closer to autotuning.

The proposal doesn't actually solve any of those problems.

OK, let me draw some lines:
1 & 2) by not having the settings be defined in a 500-line file, new users
would no longer be baffled by scores of settings which probably don't concern
them, trying to find the handful of settings which do.

3) We'd consolidate the GUC lists down from 3 places to 2, which is one less
area to synchronize. Magnus and I looked to see if it might be possible to
generate the docs from the same list, but it's not practical.

4) By shifting from a model where postgresql.conf is document-formatted and
hand-edited to one where it's machine generated, it becomes vastly easier to
write simple utilities to manage these settings. Right now, the big
"obstacle" to things like SET PERSISTENT is "how to we preseve the
hand-edited comments in the file" -- and the answer is we *don't.*

I disagree with doing any of this. It doesn't result in any useful
reduction in maintenance effort, and what it does do is make it
impossible to keep control over the detailed layout, formatting,
commenting etc in a sample postgresql.conf.

Have you *looked* at postgresql.conf.sample lately, Tom? It's a disaster.
Maintenance is already difficult, and becoming more so as we add settings.

Further, you and Simon seem to think that the current "narrative docs inside
the conf file" format has some kind of value which makes things easier for
DBAs. I don't believe it does, and I have yet to meet a *single* new
PostgreSQL user who wasn't confused and intimidated by the file.

Nor do I think that
"generate a whole config file from scratch" is going to be a useful
behavior for tuning problems --- how will you merge it with what
you had before?

Who's merging? I don't think you get the proposal. The whole "hand-edited"
approach to postgresql.conf should go away. It's not useful, it's not
educational, and it doesn't make PostgreSQL easy to manage.

Further, the lack of an easy way to manage settings via port access to
PostgreSQL is a significant inhibitor to adopting PostgreSQL in environments
with large numbers of servers. See prior arguments by the CPANEL folks about
why they don't support PostgreSQL, which is in turn a major reason why
PostgreSQL web hosting is hard to find.

I agree that editing the data about settings in the guc.c file is not ideal;
Magnus and I discussed that mainly because we wanted to preserve the
translation framework with gettext strings. If someone can think of a better
way to do this part, I'm all ears.

--
Josh Berkus
PostgreSQL @ Sun
San Francisco

"David E. Wheeler" <david@kineticode.com> writes:

I'd love to see these issues resolved. The current postgresql.conf is way over
the top. Might you have a better idea?

I don't think fiddling with surface issues like the formatting of the
postgresql.conf is productive. Hiding parameters because you don't think
beginners need them is only going to frustrate those people who do need to
adjust them.

What might be productive is picking up a group of parameters and thinking hard
about what they mean in terms of user-visible real-world effects. If they can
be recast in terms of behaviour the user wants instead of internal
implementation details then that would translate into a massive simplification
as well as being easier to explain to users.

I think we do a pretty good job of this already. Witness things like
effective_cache_size -- imagine if this were "nested_loop_cache_hit_rate" for
example, good luck figuring out what to set it to.

The vacuum cost delay factors are probably ripe for such a recast though. I
think we need just one parameter "vacuum_io_bandwidth" or something like that.
The bgwriter parameters might also be a candidate but I'm less certain.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

"Josh Berkus" <josh@agliodbs.com> writes:

It's my viewpoint based on a lot of user feedback that the current
postgresql.conf is fundamentally broken and a major roadblock to PostgreSQL
adoption. This was a point with which there was pretty much universal
agreement when I talked with people at pgCon.

Actually as a new DBA when I was first starting out with Postgres I found it
very convenient to have all the common parameters in one place where I could
just uncomment and adjust them. Instead of having to search through
documentation and find the default value from which

1 & 2) by not having the settings be defined in a 500-line file, new users
would no longer be baffled by scores of settings which probably don't concern
them, trying to find the handful of settings which do.

I'm not sure how an empty file is any less "baffling" than one listing the
default value for parameters they don't need yet.

3) We'd consolidate the GUC lists down from 3 places to 2, which is one less
area to synchronize. Magnus and I looked to see if it might be possible to
generate the docs from the same list, but it's not practical.

This seems like a trivial gain and one which is unlikely to outweigh the pain
of having to massage the info into C data structures.

4) By shifting from a model where postgresql.conf is document-formatted and
hand-edited to one where it's machine generated, it becomes vastly easier to
write simple utilities to manage these settings. Right now, the big
"obstacle" to things like SET PERSISTENT is "how to we preseve the
hand-edited comments in the file" -- and the answer is we *don't.*

What this sounds like is a sly way to try to get rid of postgresql.conf
entirely and replace it with parameters stored in the database so admins would
adjust the parameters using an SQL syntax rather than a text file.

There are pros and cons of such a system but I think for newbie admins that
would be a thousand times *more* baffling. You would have to learn new
commands and have no holistic view of what parameters had been set, what
related parameters might exist. You also have no way to keep the file in a
version control system or sync across servers etc.

Have you *looked* at postgresql.conf.sample lately, Tom? It's a disaster.
Maintenance is already difficult, and becoming more so as we add settings.

What difficulties?

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!

On May 31, 2008, at 12:36, Gregory Stark wrote:

What this sounds like is a sly way to try to get rid of
postgresql.conf
entirely and replace it with parameters stored in the database so
admins would
adjust the parameters using an SQL syntax rather than a text file.

There are pros and cons of such a system but I think for newbie
admins that
would be a thousand times *more* baffling. You would have to learn new
commands and have no holistic view of what parameters had been set,
what
related parameters might exist. You also have no way to keep the
file in a
version control system or sync across servers etc.

FWIW, this has not been a barrier to MySQL adoption.

Best,

David

Josh Berkus wrote:

Currently, PostgreSQL,conf and our set of GUC configurations suffer from
4 large problems:

As we have talked about it before, you know that I agree that the GUC system
could use some improvements. But I'm a bit surprised about some of your
assessments.

1. Most people have no idea how to set these.

Could you clarify this? I can't really believe that people are incapable of
editing a configuration file.

2. The current postgresql.conf file is a huge mess of 194 options, the
vast majority of which most users will never touch.

My opinion has always been that we should provide a default file with only the
essential options instead of all of them. I see this as a the major problem,
because people are overwhelmed and consequently don't set anything.

3. GUCS lists are kept in 3 different places (guc.c, postgresql.conf,
and the settings.sgml), which are only synched with each other manually.

While this is not ideal, I can't really see who this is a major problem, at
least from the perspective of the user.

4. We don't seem to be getting any closer to autotuning.

True. But how does your proposal address this?

On May 31, 2008, at 15:32, Peter Eisentraut wrote:

1. Most people have no idea how to set these.

Could you clarify this? I can't really believe that people are
incapable of
editing a configuration file.

I've been using PostgreSQL on and off, mostly on, for almost 10 years.
I still have no idea what 75% of those settings in postgresql.conf
mean or are for. There are an overwhelming number of them. I know that
5-8 of them I always touch, thanks largely to assistance now and then
from Josh Berkus, but the rest are just complexity to me. I don't
doubt that the vast majority of them are useful in one situation or
another, but unless I'm in one of those situations, I really don't
need to see them there and be confused by them.

Does that help?

2. The current postgresql.conf file is a huge mess of 194 options,
the
vast majority of which most users will never touch.

My opinion has always been that we should provide a default file
with only the
essential options instead of all of them. I see this as a the major
problem,
because people are overwhelmed and consequently don't set anything.

+1

Best,

David

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

In the interest of constructive criticism, here's some
ways I think postgresql.conf could be improved.

* A weak +1 to the #include idea. I'm much more inclined to simply
add a new section to the bottom of the file and use version
control, but I could see ways in which include would be useful.

* Rearrange the settings to put the more "common" ones at
the top, even if it means messing up the categories a bit.
Having 'bonjour_name' at the top, and 'default_statistics_target'
buried way down below is crazy. The sections should be
looked at from a clean perspective: do we need them at all? Are their
better ways to arrange things? What order should they be in?

* Much more verbose comments. The abovementioned default_statistics_target
is a very important settings, but there is zero explanation in the file
of what it is. The only thing we're told is that it ranges from 10 - 1000.
We can do better than that. Users would absolutely love it if each item
had a clear explanation, and it would be well worth a slightly increased
file size. See the postfix main.cf file for a good example of such.

* Remove the confusing "commented out is default" bit entirely. Simply
set each value explicitly. Why should new users have to confront this?:

# The commented-out settings shown in this file represent the default values.
# Re-commenting a setting is NOT sufficient to revert it to the default value;
# you need to reload the server.

* Lose the tabbed indenting, which looks bad, especially for multi-line
comments. Just use spaces.

* Create a tool, or at least a best practices, for controlling and tracking
changes to the file.

* Put some doc URLs in the file, at the minimum per major section. At the
very bare minimum, a real URL at the top.

* Indicate which values can be changed per-session or per-role.

* Fix the disparity between the syntax in the file and the SET interface.
For example, work_mem = 16MB works in the conf file, but you have to write
SET work_mem = '16MB'. Easiest is probably just to quote everything in the conf.

* Lose the post-value, end-of-line comments, they just get in the way when making
changes and make the file harder to read by contributing to the wrap problem.

* I'm tempted by the argument of creating a separate file for the obscure
settings, but I think it would be too much pain, and nobody would ever agree on
which settings are 'important' and which are 'obscure'.

* It might be nice to mention other ways to reload the file, such as
'service postgresql reload', or whatever Windows uses.

* The word 'paramters' is still misspelled. :)

* That whole sentence about changing the parameters as command-line
options needs to go away.

* Since the executable is now named "postgres" (thank goodness we got
rid of "postmaster"), the file should be named 'postgres.conf'. This would
also be a way to quickly distinguish 'old' vs 'new' style conf files if
we end up making major changes to it.

- --
Greg Sabino Mullane greg@turnstep.com
PGP Key: 0x14964AC8 200805311911
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhB39sACgkQvJuQZxSWSshahQCg4V5QsO34HOhUDoPzT7STcR45
V5UAoPQxkmuk/oCYirTKxMAhV+Kh8Ytz
=7Lgk
-----END PGP SIGNATURE-----

Greg Sabino Mullane wrote:

* A weak +1 to the #include idea. I'm much more inclined to simply
add a new section to the bottom of the file and use version
control, but I could see ways in which include would be useful.

We already have include directives, and have had since 8.2.

Thus spake the docs:

"In addition to parameter settings, the postgresql.conf file can contain
/include directives/, which specify another file to read and process as
if it were inserted into the configuration file at this point. Include
directives simply look like:

include 'filename'

If the file name is not an absolute path, it is taken as relative to the
directory containing the referencing configuration file. Inclusions can
be nested."

cheers

andrew

Greg Sabino Mullane wrote:

* Much more verbose comments. The abovementioned default_statistics_target
is a very important settings, but there is zero explanation in the file
of what it is. The only thing we're told is that it ranges from 10 - 1000.
We can do better than that. Users would absolutely love it if each item
had a clear explanation, and it would be well worth a slightly increased
file size. See the postfix main.cf file for a good example of such.

I kind of agree with this but actually think we should have the bare
minimum comments in the file. Why? Because our documentation links are
static. Each setting should have the URL to the full documentation on a
particular setting.

* Create a tool, or at least a best practices, for controlling and tracking
changes to the file.

This I disagree with. There are plenty of tools to handle this should
someone really want to. SVN, CVS, parrot, etc... Let systems management
be the domain of systems management.

* Put some doc URLs in the file, at the minimum per major section. At the
very bare minimum, a real URL at the top.

Hah! See above :)

* Indicate which values can be changed per-session or per-role.

Agreed. Along with this although offtopic for this post is a grid in the
docs that are explicit about this.

* Fix the disparity between the syntax in the file and the SET interface.
For example, work_mem = 16MB works in the conf file, but you have to write
SET work_mem = '16MB'. Easiest is probably just to quote everything in the conf.

Agreed.

* I'm tempted by the argument of creating a separate file for the obscure
settings, but I think it would be too much pain, and nobody would ever agree on
which settings are 'important' and which are 'obscure'.

Actually I could buy into this. There really are only about a dozen must
change settings (if that). I could see something like:

Memory settings:

network etc/network.conf
include etc/memory.conf
logging etc/logging.conf

etc...

* It might be nice to mention other ways to reload the file, such as
'service postgresql reload', or whatever Windows uses.

I think a url to the docs is a better idea here.

* The word 'paramters' is still misspelled. :)

Heh.

* Since the executable is now named "postgres" (thank goodness we got
rid of "postmaster"), the file should be named 'postgres.conf'. This would
also be a way to quickly distinguish 'old' vs 'new' style conf files if
we end up making major changes to it.

It was never postmaster.conf (that I can recall). I don't see the issue
here. Consider apache... It isn't apache.conf.

I think postgresql.conf (as that is the name of the software) makes sense.

Sincerely,

Joshua D. Drake

Can I express one's user view:

Greg Sabino Mullane writes:

* Much more verbose comments. The abovementioned default_statistics_target
is a very important settings, but there is zero explanation in the file
of what it is. The only thing we're told is that it ranges from 10 - 1000.
We can do better than that. Users would absolutely love it if each item
had a clear explanation, and it would be well worth a slightly increased
file size. See the postfix main.cf file for a good example of such.

Absolutely agreed :-). Total list of GUC and fully explanation each
of them is sufficient.
For "easy start", it might be a several postgresql.conf with
distribution, like mysql doing it,
or generate postgresql.conf by wizard-dialog before initdb starting, for
example.
But I think that all GUCs must present in configuration file.

Thanks.

Gregory Stark wrote:

I think we do a pretty good job of this already. Witness things like
effective_cache_size -- imagine if this were "nested_loop_cache_hit_rate" for
example, good luck figuring out what to set it to.

I think either of these are fine if we describe how to measure
them. Ideally if we had a GUC that said "log_nested_loop_cache_hit_rate"
that enabled some timing code (understandably with lots of overhead) that
made an attempt to measure the hit rate, it'd be easier to figure out
than the effective cache size, no?

The vacuum cost delay factors are probably ripe for such a recast though. I
think we need just one parameter "vacuum_io_bandwidth" or something like that.

+1; though perhaps the inverse of that is more useful. When my
machines are idle I'd be happy if they vacuum more. Wouldn't
we be better served specifying the I/O bandwidth of each device/tablespace
and letting vacuum use whatever portion would be otherwise idle?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Andrew Dunstan wrote:

We already have include directives, and have had since 8.2.

Heh, thanks - which proves how useless they are to me. :)

Joshua Drake wrote:

I kind of agree with this but actually think we should have the bare
minimum comments in the file. Why? Because our documentation links are
static. Each setting should have the URL to the full documentation on a
particular setting.

Ugh, why so much context switching? Put the docs next to the setting. URLs
are nice but not necessary. If you are arguing for minimum comments in
conf files, please make a patch for pg_hba.conf ;)

* Create a tool, or at least a best practices, for controlling and tracking
changes to the file.

This I disagree with. There are plenty of tools to handle this should
someone really want to. SVN, CVS, parrot, etc... Let systems management
be the domain of systems management.

Well, perhaps just a note in the docs at least that one might want to put
postgresql.conf in version control. I've seen people not doing so more often
than you would think. Perhaps because they are DBAs and not sysadmins? I also
meant a tool to do things like verify that the changes are valid, as someone
else mentioned elsewhere in this thread.

* It might be nice to mention other ways to reload the file, such as
'service postgresql reload', or whatever Windows uses.

I think a url to the docs is a better idea here.

Good point. Maybe a sort of "DBA basics" page in the docs is warranted for
things like this.

* Since the executable is now named "postgres" (thank goodness we got
rid of "postmaster"), the file should be named 'postgres.conf'. This would
also be a way to quickly distinguish 'old' vs 'new' style conf files if
we end up making major changes to it.

It was never postmaster.conf (that I can recall). I don't see the issue
here. Consider apache... It isn't apache.conf.

Not saying it ever was postmaster.conf: just that I'm glad we finally
changed the name. As for the Apache project, the httpd executable reads the
httpd.conf file. Hence, one might expect the postgres executable to read a
postgres.conf file.

- --
Greg Sabino Mullane greg@turnstep.com
End Point Corporation
PGP Key: 0x14964AC8 200806011656
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkhDEJMACgkQvJuQZxSWSsgeogCfT0g69NDoxyWGiWmDcB3PxH8h
wJ8AnjzssA7aIk0rBdJzL+bB5vSQSeBV
=lgZG
-----END PGP SIGNATURE-----

Greg Sabino Mullane wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Joshua Drake wrote:

I kind of agree with this but actually think we should have the bare
minimum comments in the file. Why? Because our documentation links are
static. Each setting should have the URL to the full documentation on a
particular setting.

Ugh, why so much context switching? Put the docs next to the setting. URLs
are nice but not necessary. If you are arguing for minimum comments in
conf files, please make a patch for pg_hba.conf ;)

Hah! Well I don't know that a minimum of comments is what I am arguing
as much as not too much comments. The comments in general in the
postgresql.conf are useless unless you have previous knowledge. I really
think that if we take advantage of the fact that we have static URLs
that life would be easier overall.

* Create a tool, or at least a best practices, for controlling and tracking
changes to the file.

This I disagree with. There are plenty of tools to handle this should
someone really want to. SVN, CVS, parrot, etc... Let systems management
be the domain of systems management.

Well, perhaps just a note in the docs at least that one might want to put
postgresql.conf in version control.

I could certainly buy into this. No reason we can't help people better
administrators. I would suggest a link to a static wiki page (on
wiki.pg) that would link to each option?

I've seen people not doing so more often
than you would think. Perhaps because they are DBAs and not sysadmins? I also
meant a tool to do things like verify that the changes are valid, as someone
else mentioned elsewhere in this thread.

pg_ctl -D data check?

I would +1 that. Including (in later releases):

WARNING: You specify 66536 for shared buffers but you only have 131072
of memory. Consider decreasing the parameter.

Obviously we would need more non math friendly wording.

* It might be nice to mention other ways to reload the file, such as
'service postgresql reload', or whatever Windows uses.

I think a url to the docs is a better idea here.

Good point. Maybe a sort of "DBA basics" page in the docs is warranted for
things like this.

Yeah I could buy into this.

* Since the executable is now named "postgres" (thank goodness we got
rid of "postmaster"), the file should be named 'postgres.conf'. This would
also be a way to quickly distinguish 'old' vs 'new' style conf files if
we end up making major changes to it.

It was never postmaster.conf (that I can recall). I don't see the issue
here. Consider apache... It isn't apache.conf.

Not saying it ever was postmaster.conf: just that I'm glad we finally
changed the name. As for the Apache project, the httpd executable reads the
httpd.conf file. Hence, one might expect the postgres executable to read a
postgres.conf file.

Maybe, but I think I would need more convincing.

Sincerely,

Joshua D. Drake