Re: Documentation of server configuration

Josh Berkus wrote:
> I disagree, absolutely and completely.   "one big alphabetical list"
> doesn't help at all in figuring out what you need to work with if
> you're running out of memory of if your queries have bad plans.
> "effective_cache_size", for example, is nowhere near
> "random_page_cost", even though both parameters affect planner choice
> of index scans.

For the record, I don't advocate "one big list".  It has turned out, for
me, however, that the current organization is so useless that it's
easier to scan through one big list than trying to find something in
the current structure.

> Further, I remember suggesting a couple months back that the
> runtime-config page was too large and ought to be broken up for
> readability.   You pooh-poohed the idea then, telling me there was
> nothing wrong with runtime-config the way it was.  Apparently you
> changed your mind?

No, I'm still saying precisely that it's already broken up too much.

> > - There are too many sections.
>
> I disagree.   In fact, I was thinking of creating some more sections.

No way.  I'm sure you all know the rule that there should be no more
than 7 items in a menu.  This is the same thing.  It's around 14 now,
depending on how you count it.  That is already way over the limit.
It's already "one big list" of its own, but not the list the user is
actually interested in.

I also find the categorization a bit suboptimal, but that is not the
point here.  I think they are too much organized after the
implementation concerns rather than trivial user concerns like
"faster", "less resources", "more secure", "better".  (For example,
what does "Write Ahead Log" or "Lock Management" do for me?  Aren't
they resource or performance concerns?)

> > - The lists of individual parameters inside the sections don't have
> > any order.
>
> Actually, there's ordered according to the frequency with which
> people monkey with that particular setting.

While that is a commendable approach, I think it's nevertheless quite
useless.  In most cases we clearly don't have that information or some
arbitrary calls have been made.  Just take any two adjacent items and
think about whether that order has any rationale in the eye of a user.

> If you want to fix runtime-config, how about an *index*?

Well, since you asked you will see that the current structure
corresponds to an index scan (albeit using an index method that is
under contention) and the one big list approach corresponds to a
sequential scan.  Now think about why the cost factors are off.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/