Thread: Re-ordering .CONF params ... questions for this list
Folks,
We've been discussing this for a while on HACKERS. However, I haven't been
getting much feedback on the specific order proposed.
Attached is an outline of my proposed re-ordering of postgresql.conf.sample.
Please send me comments. I need to submit a patch by Thursday, so don't take
too long.
This is an effort to make the order of run-time params in
postgresql.conf.sample and in the docs more logical and less baffling to the
new DBA.
Questions:
1) Should "enable_implicit_from" go in the "Version/Platform Compatibility"
section where I have it now, or in "CLIENT CONNECTIONS-Statement Behavior",
or somewhere else?
2) Where should "preload_libraries" go? I'm very reluctant to start a
"Misc." section. Perhaps I should start a "LIBRARIES" section?
3) I have re-ordered each subsection somewhat. The fixed ordering is based
on:
a) My guess at the frequency with which that option will be changed,
with more common options toward the top of the subsection;
b) Grouping for tightly related options and for options that cascade;
c) where (a) and (b) are unclear, alpha order.
Does this order make sense looking at the file?
3) Should we use indenting in PostgreSQL.conf.sample? I tend to think it
would make the file easier to read, but I'm not sure what effect it would
have, if any, on parsing the file and whether other people would find it easy
to read.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Attachment
On Tuesday 10 Jun 2003 7:01 pm, Josh Berkus wrote: > Folks, > > We've been discussing this for a while on HACKERS. However, I haven't been > getting much feedback on the specific order proposed. > > Attached is an outline of my proposed re-ordering of > postgresql.conf.sample. Please send me comments. I need to submit a patch > by Thursday, so don't take too long. > > This is an effort to make the order of run-time params in > postgresql.conf.sample and in the docs more logical and less baffling to > the new DBA. > > Questions: > 1) Should "enable_implicit_from" go in the "Version/Platform Compatibility" > section where I have it now, or in "CLIENT CONNECTIONS-Statement Behavior", > or somewhere else? Version compatibility I'd vote for (hesitantly) > 2) Where should "preload_libraries" go? I'm very reluctant to start a > "Misc." section. Perhaps I should start a "LIBRARIES" section? No useful ideas - sorry. > 3) I have re-ordered each subsection somewhat. The fixed ordering is > based on: > a) My guess at the frequency with which that option will be > changed, with more common options toward the top of the subsection; > b) Grouping for tightly related options and for options that > cascade; c) where (a) and (b) are unclear, alpha order. > Does this order make sense looking at the file? Looks good, I'd suggest the following perhaps: Logging & Debugging I'd like this near the top, but then I use syslogging. With a new install I go in and check tcpip_socket etc, fix the logging and just see if everything is working. Then I go in and do a little tuning. Actually, maybe the syslog sub-section should go above the others - say where you'll log to, and then what you'll log. Of course, I'm biased since I use syslog. Client Connection Defaults/Other/password_encryption This should probably go in the security section. Actually, looking at it "dynamic_librar_path" is in the wrong place too - cut & past error? Query Tuning/Planner Method Enabling I'm in two minds here - obviously it is more "basic" than the "cost constraints" section, but that's the one people will be tinkering with first. Nope - thinking about it, you've got it right. > 3) Should we use indenting in PostgreSQL.conf.sample? I tend to think it > would make the file easier to read, but I'm not sure what effect it would > have, if any, on parsing the file and whether other people would find it > easy to read. Not sure it would help that much - the comments need a URL to the relevant page in the online docs though. A couple more lines of comments too: # Syslog # To log to syslog, use something like # syslog = 2, syslog_facility = 'LOCAL0', syslog_ident = 'postgres' # Don't forget to update your syslog.conf then too. # ...etc Otherwise, looks good to me. -- Richard Huxton Archonet Ltd
Richard Huxton wrote: >>2) Where should "preload_libraries" go? I'm very reluctant to start a >>"Misc." section. Perhaps I should start a "LIBRARIES" section? > > No useful ideas - sorry. Sorry, I missed this earlier. This is a performance tuning option. Joe
Richard, > Logging & Debugging > I'd like this near the top, but then I use syslogging. With a new install I go > in and check tcpip_socket etc, fix the logging and just see if everything is > working. Then I go in and do a little tuning. > Actually, maybe the syslog sub-section should go above the others - say where > you'll log to, and then what you'll log. Of course, I'm biased since I use > syslog. I have no objection to moving the syslog section. Any other opinions? > Client Connection Defaults/Other/password_encryption > This should probably go in the security section. Actually, looking at it > "dynamic_librar_path" is in the wrong place too - cut & past error? Not the way I read the docs; according to the docs: password_encryption is whether or not the statement "ALTER USER joe_schmoe WITH PASSWORD 'xxxyyy'" is encrypted by default even if you don't use the "WITH ENCRYPTION" option. And it is SET-able on each client connection, by regular users. So it goes in "CLIENT CONNECTION SETTINGS". "dynamic_library_path", while less obvious, is also SETable on each client connection. I'd be happy to revise this if someone understands/uses this option and has a better idea where to put it. > Not sure it would help that much - the comments need a URL to the relevant > page in the online docs though. A couple more lines of comments too: Given that we're running out of time, I wasn't going to touch any of the comments in PostgreSQL.conf.sample. Instead, I was going to leave the comments as-is, and post extensive comments on Techdocs before 7.4 beta. Then, in 7.5 or 8.0 we can re-comment .conf. -- -Josh Berkus Aglio Database Solutions San Francisco
Josh Berkus <josh@agliodbs.com> writes:
> Given that we're running out of time, I wasn't going to touch any of the
> comments in PostgreSQL.conf.sample. Instead, I was going to leave the
> comments as-is, and post extensive comments on Techdocs before 7.4
> beta.
I doubt anyone would object to improving the comments during beta; so
you don't need to consider that part something that has to be done
before feature freeze.
regards, tom lane
Tom, > I doubt anyone would object to improving the comments during beta; so > you don't need to consider that part something that has to be done > before feature freeze. Oh, cool. OK, then ... the hard part is just deciding on what comments to include. We'll work on that in this list. -- -Josh Berkus Aglio Database Solutions San Francisco
Folks,
Revised ordering of options, based on information and suggestions received
here on both mailing lists.
--
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
Attachment
Josh- I took a quick look at your proposal on conf ordering- The groupings are great. Without a clear notion of dependencies, and only based on what I think people are likely to tweak the most, I'd suggest promoting the "client connection defaults", "version/platform compatibility" & "logging/debugging" groups to positions 2,3 & 4 respectively. Here's the thinking- You'd have all of the options that a neophyte might need to set to perform a particular task in a given environment in the first three groups. Problems encountered while setting these up might require the adventurous beginner to dip into logging/debugging to gather basic diagnostic info. With this ordering, everything you might have to touch in order to get a basic system up & running lives in the top 4 groups. (This also helps soften the dilemma of where enable_implicit_from should go by putting the two possible groups next to one another.) Below the top four groups are the tuning parameters best not messed with until one passes from neophyte to DB-Geek level. (And probably not worth messing with even then.) These are only needed when you've passed over from getting it running to needing it to run better. -Nick > -----Original Message----- > From: pgsql-performance-owner@postgresql.org > [mailto:pgsql-performance-owner@postgresql.org]On Behalf Of Josh Berkus > Sent: Tuesday, June 10, 2003 1:02 PM > To: pgsql-performance@postgresql.org > Subject: [PERFORM] Re-ordering .CONF params ... questions for this list > > > Folks, > > We've been discussing this for a while on HACKERS. However, I > haven't been > getting much feedback on the specific order proposed. > > Attached is an outline of my proposed re-ordering of > postgresql.conf.sample. > Please send me comments. I need to submit a patch by Thursday, > so don't take > too long. > > This is an effort to make the order of run-time params in > postgresql.conf.sample and in the docs more logical and less > baffling to the > new DBA. > > Questions: > 1) Should "enable_implicit_from" go in the "Version/Platform > Compatibility" > section where I have it now, or in "CLIENT CONNECTIONS-Statement > Behavior", > or somewhere else? > > 2) Where should "preload_libraries" go? I'm very reluctant to start a > "Misc." section. Perhaps I should start a "LIBRARIES" section? > > 3) I have re-ordered each subsection somewhat. The fixed > ordering is based > on: > a) My guess at the frequency with which that option will > be changed, > with more common options toward the top of the subsection; > b) Grouping for tightly related options and for options > that cascade; > c) where (a) and (b) are unclear, alpha order. > Does this order make sense looking at the file? > > 3) Should we use indenting in PostgreSQL.conf.sample? I tend to > think it > would make the file easier to read, but I'm not sure what effect it would > have, if any, on parsing the file and whether other people would > find it easy > to read. > > > > -- > -Josh Berkus > Aglio Database Solutions > San Francisco >
Nick,
> Without a clear notion of dependencies, and only based on what I think
> people are likely to tweak the most, I'd suggest promoting the "client
> connection defaults", "version/platform compatibility" & "logging/debugging"
> groups to positions 2,3 & 4 respectively.
I like your ideas, but there's two problems with them:
1) I mess around with postgresql.conf constantly, and seldom touch anything in
the "client connection defaults" section. I do, however, mess with the stuff
in the "resource usage" section, as to most of the people on this list.
2) I just spent 4.5 hours re-arranging the Runtime-config docs page last
night, and am very reluctant to do it again.
--
-Josh Berkus
______AGLIO DATABASE SOLUTIONS___________________________
Josh Berkus
Complete information technology josh@agliodbs.com
and data management solutions (415) 565-7293
for law firms, small businesses fax 621-2533
and non-profit organizations. San Francisco
> 2) I just spent 4.5 hours re-arranging the Runtime-config docs page last
> night, and am very reluctant to do it again.
I like this reason... I think you've already done a great service by
creating functional groups. The newbies won't be hurt by the need to scroll
down a bit, and the functional groupings already serve to eliminate the
confusion about what the params are for (which *does* hurt them). What
you've done is a great improvement. My additional comments below are offered
in the spirit of support for what you've already done along with thoughts to
consider for future revisions.
> 1) I mess around with postgresql.conf constantly, and seldom
> touch anything in
> the "client connection defaults" section. I do, however, mess
> with the stuff
> in the "resource usage" section, as to most of the people on this list.
I agree... but are we the folks that the conf file needs to be made more
intuitive for?
If the intent is to make it easier for experienced folks like ourselves who
are working with large or unusual databases to deal with PostgreSQL, then
certainly the resource usage and tuning settings should go to the top. We'll
set the other params once & never touch them again.
On the other hand, I suspect that the majority of postgresql users play with
the other params a bit during install to get their systems working and never
touch the resource usage or tuning params ever. (And this is as it should
be, given that the defaults are reasonable for most systems.)
Part of my motivation in offering this advice is our sibling rivalry with
MySQL- once we look under the hood, we usually find that PostgreSQL is the
way to go, but all of us mechanics spend a silly amount of time wondering
aloud why the many people who don't enjoy looking under the hood don't get
it. If we want the legions of MySQL followers to get it, we need to put only
the necessary instruments on the dashboard and not force non-mechanics to
look under the hood. (And to stretch the metaphor a bit further- The hood
latch still needs to be near the dashboard for the folks who are ready for
the next step.)
I'll cross-post this to advocacy because I'm tottering off on that tangent.
I think the comments may be useful in this forum as well because the
advocacy folks need to pass thoughts to the active developers & documenters
in much the same way that marketing folks need to communicate well with
engineers in the commercial world.
Regards,
-Nick
Nick, > I agree... but are we the folks that the conf file needs to be made more > intuitive for? > > If the intent is to make it easier for experienced folks like ourselves who > are working with large or unusual databases to deal with PostgreSQL, then > certainly the resource usage and tuning settings should go to the top. > We'll set the other params once & never touch them again. > > On the other hand, I suspect that the majority of postgresql users play > with the other params a bit during install to get their systems working and > never touch the resource usage or tuning params ever. (And this is as it > should be, given that the defaults are reasonable for most systems.) This is a good argument. Though if you pursue it, surely you're advocating a GUI tool for PostgreSQL.conf, not that that's a bad idea ... How do other people feel about this? What options in PostgreSQL.conf do you tweak most frequently? -- Josh Berkus Aglio Database Solutions San Francisco