Re: Re-ordering .CONF params ... questions for this list - Mailing list pgsql-performance

From Richard Huxton
Subject Re: Re-ordering .CONF params ... questions for this list
Date
Msg-id 200306102005.11578.richardh@archonet.com
Whole thread Raw
In response to Re-ordering .CONF params ... questions for this list  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Re-ordering .CONF params ... questions for this list
Re: Re-ordering .CONF params ... questions for this list
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning
Next
From: Bruce Momjian
Date:
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning