Skip site navigation (1) Skip section navigation (2)

Re: Re-ordering .CONF params ... questions for this list

From: Richard Huxton <richardh(at)archonet(dot)com>
To: josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org
Subject: Re: Re-ordering .CONF params ... questions for this list
Date: 2003-06-10 19:05:11
Message-ID: 200306102005.11578.richardh@archonet.com (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackerspgsql-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

In response to

Responses

pgsql-performance by date

Next:From: Bruce MomjianDate: 2003-06-10 19:08:22
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning
Previous:From: Josh BerkusDate: 2003-06-10 18:28:00
Subject: Re: FW: [ADMIN] Shared_buffers and kernel parameters, tuning

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2003-06-10 19:11:36
Subject: Re: Proposal to Re-Order Postgresql.Conf, part II
Previous:From: Robert TreatDate: 2003-06-10 18:35:19
Subject: Re: [GENERAL] Postgresql & AMD x86-64

pgsql-advocacy by date

Next:From: Richard HuxtonDate: 2003-06-10 19:09:39
Subject: Re: [GENERAL] MySQL gets $19.5 MM
Previous:From: Jean-Michel POUREDate: 2003-06-10 19:04:16
Subject: Re: PostgreSQL presentation at LSM

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group