Re: Large (8M) cache vs. dual-core CPUs

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: Bill Moran <wmoran(at)collaborativefusion(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Large (8M) cache vs. dual-core CPUs
Date: 2006-04-25 23:55:04
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-performance

On Tue, Apr 25, 2006 at 01:33:38PM -0500, Scott Marlowe wrote:
> On Tue, 2006-04-25 at 13:14, Bill Moran wrote:
> > I've been given the task of making some hardware recommendations for
> > the next round of server purchases. The machines to be purchased
> > will be running FreeBSD & PostgreSQL.
> >
> > Where I'm stuck is in deciding whether we want to go with dual-core
> > pentiums with 2M cache, or with HT pentiums with 8M cache.
> Given a choice between those two processors, I'd choose the AMD 64 x 2
> CPU. It's a significantly better processor than either of the Intel
> choices. And if you get the HT processor, you might as well turn of HT
> on a PostgreSQL machine. I've yet to see it make postgresql run faster,
> but I've certainly seen HT make it run slower.

Actually, believe it or not, a coworker just saw HT double the
performance of pgbench on his desktop machine. Granted, not really a
representative test case, but it still blew my mind. This was with a
database that fit in his 1G of memory, and running windows XP. Both
cases were newly minted pgbench databases with a scale of 40. Testing
was 40 connections and 100 transactions. With HT he saw 47.6 TPS,
without it was 21.1.

I actually had IT build put w2k3 server on a HT box specifically so I
could do more testing.
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software work: 512-231-6117
vcard: cell: 512-569-9461

In response to


Browse pgsql-performance by date

  From Date Subject
Next Message Will Reese 2006-04-26 00:02:37 Re: Slow deletes in 8.1 when FKs are involved
Previous Message Tom Lane 2006-04-25 23:09:18 Re: slow deletes on pgsql 7.4