Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 393CF9FA5CE for ; Sat, 23 Sep 2006 10:49:59 -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 76774-08 for ; Sat, 23 Sep 2006 10:49:56 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey- Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by postgresql.org (Postfix) with ESMTP id 5671C9FA47B for ; Sat, 23 Sep 2006 10:49:56 -0300 (ADT) Received: by py-out-1112.google.com with SMTP id d80so1827593pyd for ; Sat, 23 Sep 2006 06:49:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=tyFHzDU8kY+OYjX/T3tRQNmpVSxV8VtCjdDuyNrT3hkCrqYHunqp8dBcvUySbU6hLM0ab2qM/11rSRtoRvuXMO/wz6AI+3qscC2HzQoVayjOe9AvkkKywIDbLkM1I0A7NRo0ZFApilmWXriq4vFuU74eaj2vaZPbZ8EkzR95eyQ= Received: by 10.64.208.20 with SMTP id f20mr1959566qbg; Sat, 23 Sep 2006 06:49:53 -0700 (PDT) Received: by 10.64.96.15 with HTTP; Sat, 23 Sep 2006 06:49:53 -0700 (PDT) Message-ID: Date: Sat, 23 Sep 2006 15:49:53 +0200 From: "Guido Neitzer" To: "Dave Cramer" Subject: Re: Opteron vs. Xeon "benchmark" Cc: pgsql-performance@postgresql.org In-Reply-To: <0ECF3B27-A4B2-46DA-A5C6-551BADB8F2ED@fastcrypt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4513A59E.3000807@valuecare.nl> <45145AB7.70004@tweakers.net> <20060922223617.GA22923@mark.mielke.cc> <0ECF3B27-A4B2-46DA-A5C6-551BADB8F2ED@fastcrypt.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.2 tagged_above=0 required=5 tests=AWL, DNS_FROM_RFC_ABUSE, SPF_PASS X-Spam-Level: X-Archive-Number: 200609/319 X-Sequence-Number: 21005 On 9/23/06, Dave Cramer wrote: > 1) The database fits entirely in memory, so this is really only > testing CPU, not I/O which should be taken into account IMO I don't think this really is a reason that MySQL broke down on ten or more concurrent connections. The RAM might be, but I don't think so too in this case as it represents exactly what we have seen in similar tests. MySQL performs quite well on easy queries and not so much concurrency. We don't have that case very often in my company ... we have at least ten to twenty connections to the db performing statements. And we have some fairly complex statements running very often. Nevertheless - a benchmark is a benchmark. Nothing else. We prefer PostgreSQL for other reasons then higher performance (which it has for lots of situations). cug -- PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006 http://www.bignerdranch.com/news/2006-08-21.shtml