Mime-Version: 1.0 (Apple Message framework v750)
In-Reply-To: <448E11B1.20309@commandprompt.com>
References: <1150151282.14661.42.camel@tigger>
	<54CA6A16-AB42-440D-B5DB-BC43AE283ED8@blighty.com>
	<448E11B1.20309@commandprompt.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1BAED8DB-01CE-4D10-A509-91FB4DF1F04D@blighty.com>
Content-Transfer-Encoding: 7bit
From: Steve Atkins <steve@blighty.com>
Subject: Re: 64-bit vs 32-bit performance ... backwards?
Date: Mon, 12 Jun 2006 18:29:05 -0700
To: "Pgsql-Performance ((E-mail))" <pgsql-performance@postgresql.org>


On Jun 12, 2006, at 6:15 PM, Joshua D. Drake wrote:

>
>> Empirically... postgresql built for 64 bits is marginally slower  
>> than that built
>> for a 32 bit api on sparc. None of my customers have found 64 bit x86
>> systems to be suitable for production use, yet, so I've not tested  
>> on any
>> of those architectures.
>
> Really? All of our customers are migrating to Opteron and I have  
> many that have been using Opteron for over 12 months happily.

An Opteron is 64 bit capable; that doesn't mean you have to run 64 bit
code on it.

Mine're mostly reasonably conservative users, with hundreds of machines
to support. Using 64 bit capable hardware, such as Opterons, is one  
thing,
but using an entirely different linux installation and userspace  
code, say, is
a much bigger change in support terms. In the extreme case it makes no
sense to double your OS support overheads to get a single digit  
percentage
performance improvement on one database system.

That's not to say that linux/x86-64 isn't production ready for some  
users, just
that it's not necessarily a good operational decision for my  
customers. Given
my internal workloads aren't really stressing the hardware they're on  
I don't
have much incentive to benchmark x86-64 yet - by the time the numbers
might be useful to me we'll be on a different postgresql, likely a  
different
gcc/icc and so on.

Cheers,
   Steve