Re: Re-ordering .CONF params ... questions for this list
От | Richard Huxton |
---|---|
Тема | Re: Re-ordering .CONF params ... questions for this list |
Дата | |
Msg-id | 200306102005.11578.richardh@archonet.com обсуждение исходный текст |
Ответ на | Re-ordering .CONF params ... questions for this list (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: Re-ordering .CONF params ... questions for this list
(Joe Conway <mail@joeconway.com>)
Re: Re-ordering .CONF params ... questions for this list (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-performance |
On Tuesday 10 Jun 2003 7:01 pm, Josh Berkus wrote: > Folks, > > We've been discussing this for a while on HACKERS. However, I haven't been > getting much feedback on the specific order proposed. > > Attached is an outline of my proposed re-ordering of > postgresql.conf.sample. Please send me comments. I need to submit a patch > by Thursday, so don't take too long. > > This is an effort to make the order of run-time params in > postgresql.conf.sample and in the docs more logical and less baffling to > the new DBA. > > Questions: > 1) Should "enable_implicit_from" go in the "Version/Platform Compatibility" > section where I have it now, or in "CLIENT CONNECTIONS-Statement Behavior", > or somewhere else? Version compatibility I'd vote for (hesitantly) > 2) Where should "preload_libraries" go? I'm very reluctant to start a > "Misc." section. Perhaps I should start a "LIBRARIES" section? No useful ideas - sorry. > 3) I have re-ordered each subsection somewhat. The fixed ordering is > based on: > a) My guess at the frequency with which that option will be > changed, with more common options toward the top of the subsection; > b) Grouping for tightly related options and for options that > cascade; c) where (a) and (b) are unclear, alpha order. > Does this order make sense looking at the file? Looks good, I'd suggest the following perhaps: Logging & Debugging I'd like this near the top, but then I use syslogging. With a new install I go in and check tcpip_socket etc, fix the logging and just see if everything is working. Then I go in and do a little tuning. Actually, maybe the syslog sub-section should go above the others - say where you'll log to, and then what you'll log. Of course, I'm biased since I use syslog. Client Connection Defaults/Other/password_encryption This should probably go in the security section. Actually, looking at it "dynamic_librar_path" is in the wrong place too - cut & past error? Query Tuning/Planner Method Enabling I'm in two minds here - obviously it is more "basic" than the "cost constraints" section, but that's the one people will be tinkering with first. Nope - thinking about it, you've got it right. > 3) Should we use indenting in PostgreSQL.conf.sample? I tend to think it > would make the file easier to read, but I'm not sure what effect it would > have, if any, on parsing the file and whether other people would find it > easy to read. Not sure it would help that much - the comments need a URL to the relevant page in the online docs though. A couple more lines of comments too: # Syslog # To log to syslog, use something like # syslog = 2, syslog_facility = 'LOCAL0', syslog_ident = 'postgres' # Don't forget to update your syslog.conf then too. # ...etc Otherwise, looks good to me. -- Richard Huxton Archonet Ltd
В списке pgsql-performance по дате отправления:
Предыдущее
От: Josh BerkusДата:
Сообщение: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning
Следующее
От: Bruce MomjianДата:
Сообщение: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning