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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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



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

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/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"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

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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/

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly