Purchasing the correct hardware: dual-core intel? Big cache?

Derek Ragona derek at computinginnovations.com
Tue Apr 25 13:39:32 UTC 2006


Bill,

Never assume . . .

Depending on where you got the PostgreSQL, was it in binary form or 
source.  Most binarys are NOT optimized for higher end, more current 
processors, rather they are optimized for the most common family of CPU's.

But if your database application is really CPU bound, I would look at the 
data model and how your application is accessing and using the 
data.  RDBMS's can be very effiicent, or terribly inefficient.  In the 
worst case you can cause an RDBMS to serially go through every record 
searching for data or doing a calculation.

While a bigger cache may help, as may dual core CPU's, or faster CPU's.  In 
the end, you may only see marginal improvement if the application or 
database is really where you need to tune things.

         -Derek


At 08:25 AM 4/25/2006, Bill Moran wrote:
>On Tue, 25 Apr 2006 07:56:03 -0500
>Derek Ragona <derek at computinginnovations.com> wrote:
>
> > Yes, dual core is on average 20% faster than hyperthreaded CPU's.  But 
> that
> > is general benchmark.  The range of performance difference is 10% - 30%
> > depending on the application mix.
>
>Thanks.
>
> > If you use well optimized applications, you see the larger performance
> > gain.  Poor optimization causes a CPU to chug along, flushing the CPU 
> cache
> > often, and slowing things down considerably.
>
>I know.  That's why I'm so desperately trying to find a way to determine
>how often the cache is being invalidated - so I can determine whether
>larger cache sizes (such as 8M) are worthwhile.
>
>The database server is PostgreSQL.  If we find optimization problems
>with it, we'll definitely work with the PostgreSQL folks to get those
>problems addressed, but I'm not expecting a lot of poorly-written code
>in something as mature as PostgreSQL.  So, making a (reasonable)
>assumption that PostgreSQL is well-optimized, I need a way to tell if
>adding another 6M of cache will improve performance, _before_ we pay
>for it.
>
>That's my question.
>
>--
>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.
>****************************************************************
>_______________________________________________
>freebsd-questions at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>
>--
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
>MailScanner thanks transtec Computers for their support.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
MailScanner thanks transtec Computers for their support.



More information about the freebsd-questions mailing list