X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 915849FA13E for ; Tue, 13 Jun 2006 17:08:24 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 20509-07 for ; Tue, 13 Jun 2006 17:08:15 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 768249F9316 for ; Tue, 13 Jun 2006 17:08:14 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 0429756437; Tue, 13 Jun 2006 15:08:11 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Tue, 13 Jun 2006 15:08:10 -0500 Date: Tue, 13 Jun 2006 15:08:10 -0500 From: "Jim C. Nasby" To: Anthony Presley , pgsql-performance@postgresql.org Subject: Re: 64-bit vs 32-bit performance ... backwards? Message-ID: <20060613200810.GZ34196@pervasive.com> References: <1150151282.14661.42.camel@tigger> <20060613000441.GI8588@kenobi.snowman.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060613000441.GI8588@kenobi.snowman.net> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060613:anthony@resolution.com::RpOs7MJqoYomZxEI:000000000000000 0000000000000000000000000LL0 X-Hashcash: 1:20:060613:pgsql-performance@postgresql.org::dzHARTiACHBSTyPs:00000 0000000000000000000000000azo X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/201 X-Sequence-Number: 19558 On Mon, Jun 12, 2006 at 08:04:41PM -0400, Stephen Frost wrote: > don't think). This is because Postgres lets the OS handle most of the > cacheing, so as long as your OS can see all the memory you have in the Actually, in 8.1.x I've seen some big wins from greatly increasing the amount of shared_buffers, even as high as 50% of memory, thanks to the changes made to the buffer management code. I'd strongly advice users to benchmark their applications with higher shared_buffers and see what impact it has, especially if your application can't make use of really big work_mem settings. If there's additional changes to the shared buffer code in 8.2 (I know Tom's been looking at doing multiple buffer pools to reduce contention on the BufMgr lock), it'd be worth re-benchmarking when it comes out. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461