Thread: shrinking the postgresql.conf
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 -- Your PostgreSQL solutions provider, Command Prompt, Inc. 24x7 support - 1.800.492.2240, programming, and consulting Home of PostgreSQL Replicator, plPHP, plPerlNG and pgPHPToolkit http://www.commandprompt.com / http://www.postgresql.org
"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/