X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id BA5EC5292B for ; Tue, 7 Jun 2005 17:47:55 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 64573-06 for ; Tue, 7 Jun 2005 20:47:51 +0000 (GMT) Received: from mr1.surnet.cl (smtp1.surnet.cl [216.155.73.162]) by svr1.postgresql.org (Postfix) with ESMTP id C3EA25292D for ; Tue, 7 Jun 2005 17:47:49 -0300 (ADT) Received: from smtp1.surnet.cl (216.155.73.168) by mr1.surnet.cl (7.0.031.3) id 42587EDE00C77A8C; Tue, 7 Jun 2005 16:47:18 -0400 Received: from smtp1.surnet.cl (mr1.surnet.cl []) by mr1.surnet.cl ([216.155.73.168]); Tue, 07 Jun 2005 20:47:18 +0000 Received: from cluster.surnet.cl (216.155.73.164) by smtp1.surnet.cl (7.0.031.3) id 42587C6E00A279E8; Tue, 7 Jun 2005 16:47:17 -0400 Received: from localhost (200.85.216.119) by cluster.surnet.cl (7.0.024) id 4276578F004FAB94; Tue, 7 Jun 2005 16:27:29 -0400 Received: by localhost (Postfix, from userid 1000) id E3897C2DC08; Tue, 7 Jun 2005 16:27:55 -0400 (CLT) Date: Tue, 7 Jun 2005 16:27:55 -0400 From: Alvaro Herrera To: Donald Courtney Cc: Tom Arthurs , pgsql-performance@postgresql.org Subject: Re: Postgresql on an AMD64 machine Message-ID: <20050607202755.GA28361@surnet.cl> References: <1118080420.1644.23.camel@penguin1> <42A5F7B6.20502@sun.com> <42A5FB70.8090807@jobflash.com> <42A6014C.30108@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42A6014C.30108@sun.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.604 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, FORGED_RCVD_HELO X-Spam-Level: * X-Archive-Number: 200506/150 X-Sequence-Number: 12787 On Tue, Jun 07, 2005 at 04:19:24PM -0400, Donald Courtney wrote: > The system has 8 CPUs w/ 32 GB - I'm hoping to see some benefit to large > caches - > Am I missing something key with postgreSQL? Yeah. Postgres makes extensive use of the kernel's cache (or, more precisely, assumes that the kernel is doing some caching on its own). So the bulk of the memory should be left to the kernel to handle, and shared_buffers be set relatively slow. This was the standard wisdom with releases previous to 8.0; I'm not sure if anyone confirmed to still hold after the buffer manager changes in 8.0 and later in 8.1 -- we saw extensive redesign of the bufmgr on both, so the behavior may have changed. If you wanna test, I'm sure lots of people here will be interested in the results. -- Alvaro Herrera () "This is a foot just waiting to be shot" (Andrew Dunstan)