Re: shrinking the postgresql.conf
От | Mark Woodward |
---|---|
Тема | Re: shrinking the postgresql.conf |
Дата | |
Msg-id | 23037.24.91.171.78.1123534753.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: shrinking the postgresql.conf ("Joshua D. Drake" <jd@commandprompt.com>) |
Ответы |
Re: shrinking the postgresql.conf
|
Список | pgsql-hackers |
>> 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.
В списке pgsql-hackers по дате отправления: