X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id AD00AD7F18 for ; Thu, 25 Aug 2005 09:28:11 -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 55518-10 for ; Thu, 25 Aug 2005 12:28:10 +0000 (GMT) Received: from floppy.pyrenet.fr (floppy.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id 2A817D7F16 for ; Thu, 25 Aug 2005 09:28:08 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id E839130B42; Thu, 25 Aug 2005 14:40:41 +0200 (MET DST) From: Thomas Ganss X-Newsgroups: pgsql.performance Subject: Re: Caching by Postgres Date: Thu, 25 Aug 2005 14:23:49 +0100 Organization: T-Online Lines: 18 Message-ID: References: <20050823171045.12112.qmail@web51309.mail.yahoo.com> <20050823124323.710a9dd3.frank@wiles.org> <430B6DE3.6040109@sun.com> <430C7448.7030103@sun.com> <20050824173055.GA11788@mark.mielke.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet-abuse@t-online.de X-ID: Eqk63QZT8eXFIO1vXj4+shE4YiLPu+9v2BbtCVQlwLs4QKHH+vvogW User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: de-DE, de, en-us, en In-Reply-To: <20050824173055.GA11788@mark.mielke.cc> To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=2.174 required=5 tests=[FORGED_YAHOO_RCVD=2.174] X-Spam-Level: ** X-Archive-Number: 200508/468 X-Sequence-Number: 14215 > The first, to always remember - is that the move from 64-bits to > 32-bits doesn't come for free. In a real 64-bit system with a > 64-bit operating system, and 64-bit applications, pointers are > now double their 32-bit size. This means more bytes to copy around > memory, and in an extreme case, has the potential to approach > halfing both the memory latency to access many such pointers from > RAM, and half the effective amount of RAM. In real world cases, > not everything is a pointer, so this sort of performance degradation > is doubtful - but it is something to keep in mind. > In addition to the above it lessens the effects of the CPU cache, so be sure to take the larger cached versions if you have structures needing to fit into the cache... my 0.02 EUR thomas