Re: Google SoC--Idea Request

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>
Cc: "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "John DeSoi" <desoi(at)pgedit(dot)com>, "Pgsql Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Google SoC--Idea Request
Date: 2006-04-25 06:16:55
Message-ID: 10889.1145945815@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jonah H. Harris" <jonah(dot)harris(at)gmail(dot)com> writes:
> On 4/25/06, Andrew Dunstan <andrew(at)dunslane(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message ipig 2006-04-25 06:33:22 Re: Google SoC--Idea Request
Previous Message Tom Lane 2006-04-25 06:01:06 Re: [GENERAL] Concurrency problem building indexes