Received: from localhost (maia-2.hub.org [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 4469B9FA4C1 for ; Fri, 26 Jan 2007 12:22:50 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-new, port 10024) with ESMTP id 79957-01 for ; Fri, 26 Jan 2007 12:22:45 -0400 (AST) X-Greylist: delayed 00:19:41.127894 by SQLgrey-1.7.4 Received: from svr4.postgresql.org (svr4.postgresql.org [66.98.251.159]) by postgresql.org (Postfix) with ESMTP id 9A91C9FB203 for ; Fri, 26 Jan 2007 12:22:45 -0400 (AST) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.3 Received: from smtp-out.kontent.com (smtp-out001.kontent.com [81.88.40.215]) by svr4.postgresql.org (Postfix) with ESMTP id DFAA85AF91D for ; Fri, 26 Jan 2007 16:02:58 +0000 (GMT) Received: from tau.alphaset.de (xdsl-87-79-197-27.netcologne.de [87.79.197.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-out.kontent.com (Postfix) with ESMTP id 179E637C12E for ; Fri, 26 Jan 2007 17:02:49 +0100 (CET) Received: from tau.alphaset.de (tau.alphaset.de [192.168.42.1]) by tau.alphaset.de (8.13.4/8.13.4) with ESMTP id l0QFHKlN023174 for ; Fri, 26 Jan 2007 16:17:20 +0100 Received: from localhost (localhost [[UNIX: localhost]]) by tau.alphaset.de (8.13.4/8.13.6/Submit) id l0QFHKkP023169 for pgsql-performance@postgresql.org; Fri, 26 Jan 2007 16:17:20 +0100 From: Anton Rommerskirchen Reply-To: atr@atrsoft.de Organization: ATRSoft GmbH To: pgsql-performance@postgresql.org Subject: Re: Tuning Date: Fri, 26 Jan 2007 16:17:20 +0100 User-Agent: KMail/1.8 References: <76C73999206F3145A2E3046A5C32A103F02A5A@kibmail.kib.local> In-Reply-To: <76C73999206F3145A2E3046A5C32A103F02A5A@kibmail.kib.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701261617.20147.atr@atrsoft.de> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.136 tagged_above=0 required=5 tests=BAYES_50, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200701/375 X-Sequence-Number: 22976 Hello ! Am Freitag 26 Januar 2007 12:28 schrieb John Parnefjord: > Hi! > > I'm planning to move from mysql to postgresql as I believe the latter > performs better when it comes to complex queries. The mysql database > that I'm running is about 150 GB in size, with 300 million rows in the > largest table. We do quite a lot of statistical analysis on the data > which means heavy queries that run for days. Now that I've got two new > servers with 32GB of ram I'm eager to switch to postgresql to improve > perfomance. One database is to be an analysis server and the other an > OLTP server feeding a web site with pages. > > I'm setting for Postgresql 8.1 as it is available as a package in Debian > Etch AMD64. > > As I'm new to postgresql I've googled to find some tips and found some > interesting links how configure and tune the database manager. Among > others I've found the PowerPostgresql pages with a performance checklist > and annotated guide to postgresql.conf > [http://www.powerpostgresql.com/]. And of course the postgresql site > itself is a good way to start. RevSys have a short guide as well > [http://www.revsys.com/writings/postgresql-performance.html] > > I just wonder if someone on this list have some tips from the real world > how to tune postgresql and what is to be avoided. AFAIK the following > parameters seems important to adjust to start with are: > > -work_mem > -maintenance_work_mem - 50% of the largest table? > -shared_buffers - max value 50000 > -effective_cache_size - max 2/3 of available ram, ie 24GB on the Do you use a Opteron with a NUMA architecture ? You could end up with switching pages between your memory nodes, which slowed down heavily my server (Tyan 2895, 2 x 275 cpu, 8 GB)... Try first to use only one numa node for your cache. > hardware described above > -shmmax - how large dare I set this value on dedicated postgres servers? > -checkpoint_segments - this is crucial as one of the server is > transaction heavy > -vacuum_cost_delay > > Of course some values can only be estimated after database has been feed > data and queries have been run in a production like manner. > > Cheers > // John > > Ps. I sent to list before but the messages where withheld as I'm not "a > member of any of the restrict_post groups". This is perhaps due to the > fact that we have changed email address a few weeks ago and there was a > mismatch between addresses. So I apologize if any similar messages show > up from me, just ignore them. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster