Re: Google SoC--Idea Request - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Google SoC--Idea Request
Date
Msg-id 200604251316.k3PDGlH29297@candle.pha.pa.us
Whole thread Raw
In response to Re: Google SoC--Idea Request  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
> > On 4/25/06, Andrew Dunstan <andrew@dunslane.net> wrote:
> >> Personally I would much rather see a tuning advisor tool in more general
> >> use than just provide small/medium/large config setting files.
> 
> > True dat.
> 
> One thing that has to be figured out before we can go far with this
> is the whole question of how much smarts initdb really ought to have.
> Since a lot of packagers think that initdb should be run
> non-interactively behind the scenes, the obvious solution of "give
> initdb a --small/--medium/--large parameter" does not work all that
> nicely.  But on the other hand we can't just tell people to drop in
> replacement config files when the one in place contains initdb-created
> specifics, such as locale settings.
> 
> Now that there's a provision for "include" directives in
> postgresql.conf, one way to address this would be to split the
> config info into multiple physical files, some containing purely
> performance-related settings while others consider functionality.
> But that seems more like a wart than a solution to me.  I feel that
> we've pushed performance-tuning logic into initdb that probably ought
> not be there, and we ought to factor it out again.

Sounds good. I don't care what we do for 8.2, but we should do
something.

Or am I going to have to bring out my dancing elephant again?  :-)
http://www.janetskiles.com/ART/greeting/greet-ani/dancing-elephant.jpg


--  Bruce Momjian   http://candle.pha.pa.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Summary of coverity bugs
Next
From: Wes
Date:
Subject: Re: [GENERAL] Concurrency problem building indexes