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 B2FA59FA5BE for ; Tue, 13 Jun 2006 09:47:03 -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 71135-10 for ; Tue, 13 Jun 2006 09:46:55 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.aeccom.com (port-83-236-156-26.static.qsc.de [83.236.156.26]) by postgresql.org (Postfix) with ESMTP id E7E7C9FA12F for ; Tue, 13 Jun 2006 09:46:54 -0300 (ADT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.aeccom.com (Postfix) with ESMTP id 5D7FD1D03A; Tue, 13 Jun 2006 14:46:53 +0200 (CEST) Received: from mail.aeccom.com ([127.0.0.1]) by localhost (gate6.aeccom.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 32430-02-13; Tue, 13 Jun 2006 14:46:52 +0200 (CEST) Received: from [192.168.2.14] (andes.core.aeccom.com [192.168.2.14]) by mail.aeccom.com (Postfix) with ESMTP id 750A71D039; Tue, 13 Jun 2006 14:46:52 +0200 (CEST) Message-ID: <448EB3BB.9030504@aeccom.com> Date: Tue, 13 Jun 2006 14:46:51 +0200 From: Sven Geisler Organization: AEC/communications GmbH User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Luke Lonergan CC: Postgresql Performance Subject: Re: 64-bit vs 32-bit performance ... backwards? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at aeccom.com X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200606/181 X-Sequence-Number: 19538 Luke Luke Lonergan schrieb: > Sven, > On 6/13/06 5:03 AM, "Sven Geisler" wrote: >> Yes, I know. We had a problem last year with the performance of the >> Opteron. We have started the futex patch to resolve the issue. The futex >> patch itself did have no effect, but there was a side effect because the >> futex patch did use also another assembler sequence. This make a hole >> difference on a Opteron. It turned out that removing the lines >> >> cmpb >> jne >> lock >> >> was the reason why the Opteron runs faster. >> I have created a sequence of larger query with following result on >> Opteron 875 and PostgreSQL 8.0.3 >> orignal 8.0.3 => 289 query/time and 10% cpu usage >> patched 8.0.3 => 1022 query/time and 45% cpu usage > > This was in 64-bit mode on the Opteron? This was in 32-bit mode on the Opteron. But the effect was the same in 64-bit mode with PostgreSQL 8.0.3. You already get this change if you compile PostgreSQL 8.1.x in x86_64 (64-bit mode). Cheers Sven.