From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Carlos Moreno <moreno_pg(at)mochima(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Feature Request --- was: PostgreSQL Performance Tuning |
Date: | 2007-04-27 02:49:13 |
Message-ID: | 2679.1177642153@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general pgsql-performance |
Carlos Moreno <moreno_pg(at)mochima(dot)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. But
the fundamental problem remains that we don't know that much about
how the installation will be used. For example, the planner
configuration parameters turn out to have not that much to do with the
absolute speed of your drive, and a whole lot to do with the ratio
of the size of your database to the amount of RAM you've got; and the
ultimate size of the DB is one thing initdb certainly can't guess.
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-04-27 02:54:20 | Re: DIfferent plans for explicit versus implicit join using link table |
Previous Message | John D. Burger | 2007-04-27 02:25:54 | Re: DIfferent plans for explicit versus implicit join using link table |
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 2007-04-27 04:42:37 | Re: index structure for 114-dimension vector |
Previous Message | Carlos Moreno | 2007-04-27 01:58:53 | Feature Request --- was: PostgreSQL Performance Tuning |