Tom Lane wrote:
Carlos Moreno <moreno_pg@xxxxxxxxxxx> 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
--
