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 783B85292F for ; Wed, 8 Jun 2005 06:52:02 -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 68299-10 for ; Wed, 8 Jun 2005 09:51:52 +0000 (GMT) Received: from vms040pub.verizon.net (vms040pub.verizon.net [206.46.252.40]) by svr1.postgresql.org (Postfix) with ESMTP id 904315292D for ; Wed, 8 Jun 2005 06:51:51 -0300 (ADT) Received: from osgiliath.mathom.us ([70.108.120.78]) by vms040.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IHR00GXLFEELW07@vms040.mailsrvcs.net> for pgsql-performance@postgresql.org; Wed, 08 Jun 2005 04:51:50 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by osgiliath.mathom.us (Postfix) with ESMTP id 22A3F60E032 for ; Wed, 08 Jun 2005 05:51:50 -0400 (EDT) Received: from osgiliath.mathom.us ([127.0.0.1]) by localhost (osgiliath [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31404-03-6 for ; Wed, 08 Jun 2005 05:51:50 -0400 (EDT) Received: by osgiliath.mathom.us (Postfix, from userid 1000) id 0B29460E031; Wed, 08 Jun 2005 05:51:50 -0400 (EDT) Date: Wed, 08 Jun 2005 05:51:50 -0400 From: Michael Stone Subject: Re: Postgresql on an AMD64 machine In-reply-to: <26813.1118202633@sss.pgh.pa.us> To: pgsql-performance@postgresql.org Mail-Followup-To: pgsql-performance@postgresql.org Message-id: <20050608095149.GB19513@mathom.us> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-disposition: inline X-Pgp-Fingerprint: 53 FF 38 00 E7 DD 0A 9C 84 52 84 C5 EE DF 7C 88 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mathom.us References: <1118080420.1644.23.camel@penguin1> <20050607202755.GA28361@surnet.cl> <18285.1118178689@sss.pgh.pa.us> <200506072005.47418.josh@agliodbs.com> <26813.1118202633@sss.pgh.pa.us> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.013 tagged_above=0 required=5 tests=AWL X-Spam-Level: X-Archive-Number: 200506/162 X-Sequence-Number: 12799 On Tue, Jun 07, 2005 at 11:50:33PM -0400, Tom Lane wrote: >Again, let's see some evidence that it's worth putting effort into that. >(Offhand it seems this is probably an easier fix than changing the >shared-memory allocation code; but conventional wisdom is that really >large values of work_mem are a bad idea, and I'm not sure I see the case >for maintenance_work_mem above 2Gb either.) Hmm. That would be a fairly hard thing to test, no? I wouldn't expect to see a smooth curve as the value is increased--I'd expect it to remain fairly flat until you hit the sweet spot where you can fit the whole working set into RAM. When you say "2Gb", does that imply that the memory allocation limit in 8.1 has been increased from 1G-1? Mike Stone