On Tue, 14 Oct 2008, Kevin Murphy wrote:
One thing that might help people swallow the off-putting default "toy
mode" performance of PostgreSQL would be an explanation of why
PostgreSQL uses its shared memory architecture in the first place.
I doubt popularizing the boring technical details behind UNIX memory
allocation sematics would help do anything but reinforce PostgreSQL's
reputation for being complicated to setup. This same problem exists with
most serious databases, as everyone who has seen ORA-27123 can tell you.
What we need is a tool to help people manage those details if asked.
http://www.ibm.com/developerworks/db2/library/techarticle/dm-0509wright/
shows a good example; DB2's "probe" tool does this little bit of tuning
for you:
DB2 has automatically updated the "shmmax" kernel
parameter from "33554432" to the recommended value "268435456".
And you're off--it bumped that from the default 32MB to 256MB. The
problem for PostgreSQL is that nobody who is motivated enough to write
such magic for a large chunk of the supported platforms has had the time
to do it yet. I'll get to that myself eventually even if nobody else
does, as this is a recurring problem I'd like to make go away.
--
* Greg Smith gsmith@xxxxxxxxxxxxx http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
