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 AC4AD9FA4A8 for ; Mon, 12 Jun 2006 20:19:56 -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 40234-10 for ; Mon, 12 Jun 2006 20:19:45 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from skunk.mtbrook.bozemanpass.com (unknown [69.145.82.195]) by postgresql.org (Postfix) with ESMTP id 335DA9FA10A for ; Mon, 12 Jun 2006 20:19:46 -0300 (ADT) Received: from [69.145.82.218] (unknown [69.145.82.218]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id A28025582AA for ; Mon, 12 Jun 2006 16:19:43 -0700 (PDT) Message-ID: <448DF692.3070906@boreham.org> Date: Mon, 12 Jun 2006 17:19:46 -0600 From: David Boreham Reply-To: david_list@boreham.org User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: 64-bit vs 32-bit performance ... backwards? References: <1150151282.14661.42.camel@tigger> In-Reply-To: <1150151282.14661.42.camel@tigger> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/145 X-Sequence-Number: 19502 Anthony Presley wrote: >I had an interesting discussion today w/ an Enterprise DB developer and >sales person, and was told, twice, that the 64-bit linux version of >Enterprise DB (which is based on the 64-bit version of PostgreSQL 8.1) >is SIGNIFICANTLY SLOWER than the 32-bit version. Since the guys of EDB >are PostgreSQL ..... has anyone seen that the 64-bit is slower than the >32-bit version? > >I was told that the added 32-bits puts a "strain" and extra "overhead" >on the processor / etc.... which actually slows down the pointers and >necessary back-end "stuff" on the database. > >I'm curious if anyone can back this up .... or debunk it. It's about >the polar opposite of everything I've heard from every other database >vendor for the past several years, and would be quite an eye-opener for >me. > > What they are saying is strictly true : 64-bit pointers tend to increase the working set size of an application vs. 32-bit pointers. This means that any caches will have somewhat lower hit ratio. Also the bytes/s between the CPU and memory will be higher due to moving those larger pointers. In the case of a 32-bit OS this also applies to the kernel so the effect will be system-wide. However, an application that needs to work on > around 2G of data will in the end be much faster 64-bit due to reduced I/O (it can keep more of the data in memory). I worked on porting a large database application from 32-bit to 64-bit. One of our customers required us to retain the 32-bit version because of this phenomenon. In measurements I conducted on that application, the performance difference wasn't great (10% or so), but it was measurable. This was with Sun Sparc hardware. It is possible that more modern CPU designs have more efficient 64-bit implementation than 32-bit, so the opposite might be seen too. Whether or not PG would show the same thing I can't say for sure. Probably it would though.