> 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
