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

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: Large (8M) cache vs. dual-core CPUs
Date: 2006-04-25 18:14:35
Message-ID: 20060425141435.6c8c163c.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


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.

Both of these are expensive bits of hardware, and I'm trying to
gather as much evidence as possible before making a recommendation.
The FreeBSD community seems pretty divided over which is likely to
be better, and I have been unable to discover a method for estimating
how much of the 2M cache on our existing systems is being used.

Does anyone in the PostgreSQL community have any experience with
large caches or dual-core pentiums that could make any recommendations?
Our current Dell 2850 systems are CPU bound - i.e. they have enough
RAM, and fast enough disks that the CPUs seem to be the limiting
factor. As a result, this decision on what kind of CPUs to get in
the next round of servers is pretty important.

Any advice is much appreciated.

--
Bill Moran
Collaborative Fusion Inc.

****************************************************************
IMPORTANT: This message contains confidential information and is
intended only for the individual named. If the reader of this
message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2006-04-25 18:20:29 Re: Slow queries salad ;)
Previous Message Dave Dutcher 2006-04-25 18:03:13 Re: planner not using index for like operator