Greg Smith wrote:
As for SCSI vs. SATA, I collected up the usual arguments on both sides at http://www.postgresqldocs.org/index.php/SCSI_vs._IDE/SATA_Disks
Why do you claim that 'More platters also means slower seeks and generally slower performance.'? On the face of it, it should mean that the number of track step operations is reduced, even if the drive doesn't buffer a slice of tracks aross all platters (which would help if it did). I'm not entirely sure why the extra platters should really count as more moving parts since I think the platter assembly and head assembly are both single parts in effect, albeit they will be more massive with more platters. I'm not sure how much extra bearing friction that will mean, but it is reasonable that some extra energy is going to be needed. Recent figures I've seen suggest that the increased storage density per platter, plus the extra number of platters, means that the streaming speed of good 7200rpm SATA drives is very close to that of good 15000rpm SAS drives - and you can choose which bit of the disk to use to reduce seek time and maximise transfer rate with the oversize drives. You can get about 100MB/s out of both technologies, streaming. It may be worth considering an alternative approach. I suspect that a god RAID1 or RAID1+0 is worthwhile for WAL, but you might consider a RAID1 of a pair of SSDs for data. They will use a lot of your budget, but the seek time is negligible so the effective usable performance is higher than you get with spinning disks - so you might trade a fancy controller with battery-backed cache for straight SSD. I haven't done this, so YMMV. But the prices are getting interesting for OLTP where most disks are massively oversized. The latest Samsung and SanDisk are expensive in the UK but the Transcend 16GB TS16GSSD25S-S SATA is about $300 equiv - it can do 'only' 'up to' 28MB/s write and you wouldn't want to put WAL on one, but sustaining 15-20MB/s through random access to a real disk isn't trivial. If average access is 10ms, and you write 100MB/s streaming, then you have to ask yourself if you going to do 80 or more seeks a second. James James -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
