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