| From: | Greg Smith <gsmith(at)gregsmith(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Sorting Improvements for 8.4 |
| Date: | 2007-12-20 04:31:16 |
| Message-ID: | Pine.GSO.4.64.0712192237170.20926@westnet.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 20 Dec 2007, Gregory Stark wrote:
> Surely such machines have kickass memory backplanes too though? How could it
> ever be reasonable to have an i/o controller with more bandwidth than your
> memory?
Dann had the right general numbers here--max of 6.4GB/s between processors
and you might coax an aggregate of double that out of the DDR RAM with 2
4-way interleaved banks of memory. Let's call it 12GB/s theoretical max.
If the theoretical max of the disks is 2GB/s, that's only a 6:1 headroom,
and with a decent cache rate it's not outrageous to imagine you could
bottleneck on memory with some things before you run out of disk
throughput.
Right now I think a lot of the disk bottlenecks are seek-limited more than
anything, but SSD will knock that one out for apps that are more about
throughput than maximum storage. I could already switch to SDD usefully
today for some of what I do that's in that category, it's just a bit too
expensive to do yet; soon, though.
Just trying to usefully estimate where the edge of that back of the
envelope should go to.
--
* Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com Baltimore, MD
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Koichi Suzuki | 2007-12-20 07:55:30 | Re: Benchmark for GiST index? |
| Previous Message | Dan Langille | 2007-12-20 03:40:18 | PGCon 2008 - call for papers |