public inbox for [email protected]  

help / color / mirror / Atom feed

From: Peter Eisentraut <[email protected]>
To: Josh Berkus <[email protected]>
Cc: [email protected]
Subject: Re: Documentation of server configuration
Date: Sun, 14 Nov 2004 11:45:44 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

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/

view thread (22+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Documentation of server configuration
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox