shrinking the postgresql.conf

"Joshua D. Drake" <jd@commandprompt.com> writes:

As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?

What? The contents of postgresql.conf *are* documentation.

regards, tom lane

Hello,

As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?

Considering many of the options can already be altered using SET why
not make it the default for many of them?

Sincerely,

Joshua D. Drake

Well, if you want PostgreSQL to act a specific way, then you are going to
have to set up the defaults somehow, right?

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?

I periodically get into arguments on hackers because I want *more* options
available in postgresql.conf

My dream is to start postgres like:

/opt/postgres/bin/postmaster --config-file=/opt/postgres/bases/tiger.conf
or
/opt/postgres/bin/postmaster --config-file=/opt/postgres/bases/zipcode.conf

I also want an include directve that allows production or debugging
settings to be easily used.

Tom Lane wrote:

"Joshua D. Drake" <jd@commandprompt.com> writes:

As I have been laboring over the documentation of the postgresql.conf
file for 8.1dev it seems that it may be useful to rip out most of the
options in this file?

What? The contents of postgresql.conf *are* documentation.

Yes there are documentation bits in the postgresql.conf but they are in
no way the level of what a book entails, or even a badly written article.

My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.

Sincerely,

Joshua D> Drake

regards, tom lane

--
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/

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.

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.

I periodically get into arguments on hackers because I want *more* options
available in postgresql.conf

Then I think we will have to agree to disagree ;).

My dream is to start postgres like:

/opt/postgres/bin/postmaster --config-file=/opt/postgres/bases/tiger.conf
or
/opt/postgres/bin/postmaster --config-file=/opt/postgres/bases/zipcode.conf

You can do that easily if you have multiple catalogs which is what we do
when we want that.

I also want an include directve that allows production or debugging
settings to be easily used.

Such as?

Sincerely,

Joshua D. Drake

--
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/

"Joshua D. Drake" <jd@commandprompt.com> writes:

My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.

[ shrug... ] Then we would have two incompatible mechanisms instead of one.
(We can't eliminate the flat file completely, for the simple reason that
some of the settings have to be accessible before the database is up enough
to read a table. Much less *write* a table ... how would you do initial
configuration in such a setup?) And a table would be less friendly than
a flat file in terms of documentation, flexibility for adding user
comments, etc. I can't get excited about this.

regards, tom lane

Josh,

My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.

You were aware of the virtual view pg_settings, right?

I've considered before adjusting pg_settings so that it would take UPDATEs and
convert them to SET statements. However, I'm not really sure what the
benefit of this would be.

As for making PostgreSQL.conf shorter, I'm personally always open to
suggestions of settings which are useless and could be removed (backed by
testing, of course). See our earlier discussion on commit_siblings.

ANd if you think PostgreSQL is bad, you should see Oracle ...

--
Josh Berkus
Aglio Database Solutions
San Francisco

Josh Berkus wrote:

Josh,

My actual point was that we could put a lot of the options in a global
table that could be adjusted versus having the flat file.

You were aware of the virtual view pg_settings, right?

Yes and show all.

I've considered before adjusting pg_settings so that it would take UPDATEs and
convert them to SET statements. However, I'm not really sure what the
benefit of this would be.

Well it wouldn't be unless it stuck from a reload or restart.

As for making PostgreSQL.conf shorter, I'm personally always open to
suggestions of settings which are useless and could be removed (backed by
testing, of course). See our earlier discussion on commit_siblings.

ANd if you think PostgreSQL is bad, you should see Oracle ...

Heh, I have. :)"

Sincerely,

Joshua D. Drake

--
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/

On 2005-08-08, Josh Berkus <josh@agliodbs.com> wrote:

I've considered before adjusting pg_settings so that it would take UPDATEs
and convert them to SET statements. However, I'm not really sure what the
benefit of this would be.

It's done that (via rules) since at least as far back as 7.4, no?

(Though it suffers from the usual problem in that it rewrites an UPDATE
into a SELECT, resulting in an UPDATE command that returns tuples, which is
known to break some client interfaces.)

--
Andrew, Supernews
http://www.supernews.com - individual and corporate NNTP services

Josh Berkus <josh@agliodbs.com> writes:

I've considered before adjusting pg_settings so that it would take
UPDATEs and convert them to SET statements.

Uh, it's always done that. The issue here would be making it do
something with more persistent effect than a SET.

regards, tom lane

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?

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.

I periodically get into arguments on hackers because I want *more*
options
available in postgresql.conf

Then I think we will have to agree to disagree ;).

True.

My dream is to start postgres like:

/opt/postgres/bin/postmaster
--config-file=/opt/postgres/bases/tiger.conf
or
/opt/postgres/bin/postmaster
--config-file=/opt/postgres/bases/zipcode.conf

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.

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.

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/