From: Carlos Moreno <moreno_pg@mochima.com>
To: PostgreSQL Performance <pgsql-performance@postgresql.org>
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
Date: Fri, 27 Apr 2007 09:27:49 -0400
Message-ID: <4631FA55.4010406@mochima.com> (raw)
In-Reply-To: <2679.1177642153@sss.pgh.pa.us>
References: <OFC96167D5.6BB63AC2-ON652572C9.003B5263-652572C9.003E4142@lntinfotech.com>
<46310247.2050802@pinpointresearch.com>
<463158DD.3060602@mochima.com>
<2679.1177642153@sss.pgh.pa.us>
Tom Lane wrote:
> Carlos Moreno <moreno_pg@mochima.com> writes:
>
>> ... But, wouldn't it make sense that the configure script
>> determines the amount of physical memory and perhaps even do a HD
>> speed estimate to set up defaults that are closer to a
>> performance-optimized
>> configuration?
>>
>
> No. Most copies of Postgres these days are executed on machines very
> far away from where the code was built. It's a little bit safer to
> try to tune things at initdb time ... as indeed we already do.
D'oh! Yes, that makes more sense, of course.
> But
> the fundamental problem remains that we don't know that much about
> how the installation will be used.
Notice that the second part of my suggestion covers this --- have
additional
switches to initdb so that the user can tell it about estimates on how
the DB
will be used: estimated size of the DB, estimated percentage of
activity that
will involve writing, estimated percentage of activity that will be
transactions,
percentage that will use indexes, percentage of queries that will be
complex,
etc. etc.
Wouldn't initdb be able to do a better job at coming up with sensible
defaults if it counts on this information? Of course, all these
parameters
would have their own defaults --- the user won't necessarily know or have
an accurate estimate for each and every one of them.
> Also, there is an extremely good reason why Postgres will never be set
> up to try to take over the whole machine by default: most of the
> developers run multiple postmasters on their machines.
>
Wouldn't this be covered by the above suggestion?? One of the switches
for the command initdb could allow the user to specify how many instances
will be run (I assume you're talking about having different instances
listening
on different ports for increased concurrency-related benefits?)
Does my suggestion make more sense now? Or is it still too unrealistic to
make it work properly/safely?
Carlos
--
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: moreno_pg@mochima.com
Subject: Re: Feature Request --- was: PostgreSQL Performance Tuning
In-Reply-To: <4631FA55.4010406@mochima.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox