Skip site navigation (1) Skip section navigation (2)

Re: Opteron vs. Xeon "benchmark"

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Guido Neitzer <guido(dot)neitzer(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Opteron vs. Xeon "benchmark"
Date: 2006-09-23 14:19:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 23-Sep-06, at 9:49 AM, Guido Neitzer wrote:

> On 9/23/06, Dave Cramer <pg(at)fastcrypt(dot)com> 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).

I should make myself clear. I like the results of the benchmark. But  
I wanted to keep things in perspective.

> cug
> -- 
> PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006
> ---------------------------(end of  
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
>       subscribe-nomail command to majordomo(at)postgresql(dot)org so that  
> your
>       message can get through to the mailing list cleanly

In response to

pgsql-performance by date

Next:From: Ron MayerDate: 2006-09-24 13:29:50
Subject: Re: Large tables (was: RAID 0 not as fast as
Previous:From: Guido NeitzerDate: 2006-09-23 13:49:53
Subject: Re: Opteron vs. Xeon "benchmark"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group