Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 6EEA664FD91 for ; Tue, 14 Oct 2008 19:23:14 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 52368-04 for ; Tue, 14 Oct 2008 19:23:11 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id 8681464FD72 for ; Tue, 14 Oct 2008 19:23:11 -0300 (ADT) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id m9EMN9xO023407; Tue, 14 Oct 2008 18:23:09 -0400 (EDT) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id m9EMN9dO023399; Tue, 14 Oct 2008 18:23:09 -0400 (EDT) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Tue, 14 Oct 2008 18:23:09 -0400 (EDT) From: Greg Smith X-X-Sender: gsmith@westnet.com To: Kevin Murphy cc: pgsql-general@postgresql.org Subject: Re: Drupal and PostgreSQL - performance issues? In-Reply-To: <48F4B3C2.1050805@genome.chop.edu> Message-ID: References: <2434A118-CEFA-43A9-BA88-006EC1F80326@hoegh.org> <200810122214.53558.uwe@oss4u.com> <20081013090228.248a665f@dawn.webthatworks.it> <20081014114011.0ebe495a@dawn.webthatworks.it> <3250B5B6-B507-4E79-BAF0-E98B73E9FED9@hoegh.org> <48F4B3C2.1050805@genome.chop.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/579 X-Sequence-Number: 138828 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@gregsmith.com http://www.gregsmith.com Baltimore, MD