From: | "Matthew Nuzum" <matt(dot)followers(at)gmail(dot)com> |
---|---|
To: | <pgsql-performance(at)postgresql(dot)org>, "'Steve Poe'" <spoe(at)sfnet(dot)cc> |
Subject: | Re: Spend 7K *WHERE*? WAS Intel SRCS16 SATA raid? and How |
Date: | 2005-04-15 20:43:47 |
Message-ID: | 42602785.602f27fb.2c70.0ad4@mx.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
I think there are many people who feel that $7,000 is a good budget for a
database server, me being one.
* I agree with the threads that more disks are better.
* I also agree that SCSI is better, but can be hard to justify if your
budget is tight, and I have great certainty that 2x SATA drives on a good
controller is better than x SCSI drives for many work loads.
* I also feel that good database design and proper maintenance can be one
of the single biggest performance enhancers available. This can be labor
intensive, however, and sometimes throwing more hardware at a problem is
cheaper than restructuring a db.
Either way, having a good hardware platform is an excellent place to start,
as much of your tuning will depend on certain aspects of your hardware.
So if you need a db server, and you have $7k to spend, I'd say spend it.
>From this list, I've gathered that I/O and RAM are your two most important
investments.
Once you get that figured out, you can still do some performance tuning on
your new server using the excellent advice from this mailing list.
By the way, for all those who make this list work, I've rarely found such a
thorough, helpful and considerate group of people as these on the
performance list.
--
Matthew Nuzum <matt(at)followers(dot)net>
www.followers.net - Makers of "Elite Content Management System"
View samples of Elite CMS in action by visiting
http://www.followers.net/portfolio/
From | Date | Subject | |
---|---|---|---|
Next Message | Enrico Weigelt | 2005-04-15 20:55:11 | immutable functions vs. join for lookups ? |
Previous Message | Enrico Weigelt | 2005-04-15 20:40:55 | Re: clear function cache (WAS: SQL function inlining) |