Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 9DB932E0295 for ; Tue, 11 Dec 2007 20:07:50 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 50841-03 for ; Tue, 11 Dec 2007 20:07:35 -0400 (AST) Received: from westnet.com (westnet.com [216.187.52.2]) by postgresql.org (Postfix) with ESMTP id A75462E0150 for ; Tue, 11 Dec 2007 20:07:39 -0400 (AST) Received: from westnet.com (localhost [127.0.0.1]) by westnet.com (8.14.0/8.14.0) with ESMTP id lBC07c7F025198; Tue, 11 Dec 2007 19:07:38 -0500 (EST) Received: from localhost (gsmith@localhost) by westnet.com (8.14.0/8.13.2/Submit) with ESMTP id lBC07cuF025194; Tue, 11 Dec 2007 19:07:38 -0500 (EST) X-Authentication-Warning: westnet.com: gsmith owned process doing -bs Date: Tue, 11 Dec 2007 19:07:38 -0500 (EST) From: Greg Smith X-X-Sender: gsmith@westnet.com To: kelvan cc: pgsql-performance@postgresql.org Subject: Re: database tuning In-Reply-To: Message-ID: References: <1197016760.4255.474.camel@ebony.site> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/157 X-Sequence-Number: 27973 On Wed, 12 Dec 2007, kelvan wrote: > my original question is what are the overheads for postgres but obviously no > one knows or no one knows where a webpage containing this information is -_- In addition to the documentation links people have already suggested, I'd also suggest http://andreas.scherbaum.la/blog/archives/282-table-size,-database-size.html which gives some helpful suggestions on measuring the actual size of data you've got in the database already. It's possible to make a mistake when trying to compute overhead yourself; loading a subset of the data and measuring the size is much less prone to error. > if we were not using a Mac we would have none of the problems we have > with connection issues such as php seems to want to take up 20 db > connections at a time I can't imagine why the connection pooling links I suggested before wouldn't work perfectly fine on a Mac. You're correct to first nail down why PHP is connecting more than you expect, but eventually I suspect you'll need to wander toward pooling. > neither I nor the web app developer are Mac savvy hell as far as we have > seen no Mac tec is Mac savvy either :) > we cannot get parts of postgres to run on a Mac either such as pgagent > which is necessary for us but we cannot seem to find a daemon that works > on a Mac You might want to give some specifics and ask about this on the pgAdmin mailing list: http://www.pgadmin.org/support/list.php OS X support is relatively recent for pgAdmin and I see some other recent fixes for specific issues on that platform. -- * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD