Re: Proposal to Re-Order Postgresql.Conf, part II

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Proposal to Re-Order Postgresql.Conf, part II
Дата
Msg-id 200306051116.53090.josh@agliodbs.com
обсуждение исходный текст
Ответ на Re: Proposal to Re-Order Postgresql.Conf, part II  (Rod Taylor <rbt@rbt.ca>)
Ответы Re: Proposal to Re-Order Postgresql.Conf, part II  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 BerkusAglio Database SolutionsSan Francisco



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: UPDATE ... SET = DEFAULT
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: UPDATE ... SET = DEFAULT