| From: | Ben Chobot <bench(at)silentmedia(dot)com> | 
|---|---|
| To: | PostgreSQL Performance <pgsql-performance(at)postgresql(dot)org> | 
| Subject: | hardware priority for an SSD database? | 
| Date: | 2009-12-23 22:10:55 | 
| Message-ID: | B465474F-A497-4A9D-ADD1-7E906154061D@silentmedia.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-performance | 
We're looking to upgrade our database hardware so that it can sustain  
us while we re-architect some of the more fundamental issues with our  
applications. The first thing to spend money on is usually disks, but  
our database currently lives almost entirely on flash storage, so  
that's already nice and fast. My question is, what we should spend  
money on next?
With most data stored in flash, does it still make sense to buy as  
much ram as possible? RAM is still faster than flash, but while it's  
cheap, it isn't free, and our database is a couple hundred GB in size.
We also have several hundred active sessions. Does it makes sense to  
sacrifice some memory speed and go with 4 6-core Istanbul processors?  
Or does it make more sense to limit ourselves to 2 4-core Nehalem  
sockets and get Intel's 1333 MHz DDR3 memory and faster cores?
Our queries are mostly simple, but we have a lot of them, and their  
locality tends to be low. FWIW, about half are selects.
Does anybody have any experience with these kinds of tradeoffs in the  
absence of spinning media? Any insight would be much appreciated. From  
the information I have right now, trying to figuring out how to  
optimally spend our budget feels like a shot in the dark.
Thanks!
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Smith | 2009-12-24 00:26:06 | Re: hardware priority for an SSD database? | 
| Previous Message | Robert Haas | 2009-12-21 01:56:58 | Re: Idea how to get rid of Bitmap Heap Scan |