Re: shrinking the postgresql.conf

Mark Woodward wrote:
>>>Well, if you want PostgreSQL to act a specific way, then you are going
>>>to
>>>have to set up the defaults somehow, right?
>>
>>Of course, which is why we could use a global table for most of it.
> 
> 
> What if you wish to start the same database cluster with different settings?

Then change the setting and restart?

>>>Which is cleaner? Using a configuration file which is going to be there
>>>anyway, or trying to rig-up some sort of autostart.sql mechanism to put
>>>PostgreSQL into its desired state?
>>
>>Initdb could easily create this as part of the catalog/cluster.
> 
> 
> Assuming you know the tuning parameters at creation time, hint: you don't.

Which isn't any different than now. You don't have a postgresql.conf 
until you initdb, well you do but most people don't know about it.

>>You can do that easily if you have multiple catalogs which is what we do
>>when we want that.
> 
> 
> I *really* dislike this sort of strategy.

It works great for us :) but each person has their own needs.

> 
>>>I also want an include directve that allows production or debugging
>>>settings to be easily used.
>>>
>>
>>Such as?
> 
> 
> Printing out statement execution, timing, etc. obviously.

Well this can be done easily as having a debug conf and a prod conf.
Copy one over the other and HUP when required....

> 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster


-- 
Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240
PostgreSQL Replication, Consulting, Custom Programming, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/