From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | Rod Taylor <rbt(at)rbt(dot)ca> |
Cc: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Proposal to Re-Order Postgresql.Conf, part II |
Date: | 2003-06-05 18:16:53 |
Message-ID: | 200306051116.53090.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Rod,
> > 4) Does anyone else have any comments on the proposed re-ordering?
>
> Since we're painting a shed, does it make sense to put the items in
> alphabetical order for each section?
I thought about that, yes. However, I find that most items have a logical
order that is not alphabetical. Take the WAL section for example:
"fsync" needs to go first, because if it is set to "false" the rest of the WAL
settings don't matter.
"wal_sync_method" and "wal_buffers" are the "most important" (or, at least,
most likely to be tinkered with) settings so they sould go immdiately after.
"checkpoint_segments, checkpoint_timeout, commit_delay, commit_siblings" are
all directly related and should to appear in that order (which, oddly enough,
happens to be alphabetical).
"wal_debug" is seldom used outside of Postgresql source development or unusual
system failures, and should therefore go last.
I have tried to order other parameters by applying the same logic, which
essentially amounts to: order by most important/most likely to be changed,
grouping settings that need to be manipulated together. I'd be happy to
hear your comments on my application of that logic.
BTW, everyone: I do not seem to be receiving any Postgresql.org mail since
the server crash & restoration. So please cc: any comments directly to me!
--
-Josh Berkus
Aglio Database Solutions
San Francisco
From | Date | Subject | |
---|---|---|---|
Next Message | Rod Taylor | 2003-06-05 18:39:36 | Re: Proposal to Re-Order Postgresql.Conf, part II |
Previous Message | Rod Taylor | 2003-06-05 17:29:31 | Re: Proposal to Re-Order Postgresql.Conf, part II |