Why do you claim that 'More platters also means slower seeks
and generally slower performance.'?

        More platters -> more heads -> heavier head assembly -> slower seek time
        But..
More platters -> higher density -> less seek distance (in mm of head movement) -> faster seek time

As usual, no clear-cut case, a real-life test would tell more interesting things.

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.

Since the bearings are only on one side of the axle (not both), a heavier platter assembly would put more stress on the bearing if the disk is subject to vibrations (like, all those RAID disks seeking together) which would perhaps shorten its life. Everything with conditionals of course ;) I remember reading a paper on vibration from many RAID disks somewhere a year or so ago, vibration from other disks seeking at the exact same time and in the same direction would cause resonances in the housing chassis and disturb the heads of disks, slightly worsening seek times and reliability. But, on the other hand, the 7 disks raided in my home storage server never complained, even though the $30 computer case vibrates all over the place when they seek. Perhaps if they were subject to 24/7 heavy torture, a heavier/better damped chassis would be a good investment.

It may be worth considering an alternative approach. I suspect
that a god RAID1 or RAID1+0 is worthwhile for WAL, but

Actually, now that 8.3 can sync to disk every second instead of at every commit, I wonder, did someone do some enlightening benchmarks ? I remember benchmarking 8.2 on a forum style load and using a separate disk for WAL (SATA, write cache off) made a huge difference (as expected) versus one disk for everything (SATA, and write cache off). Postgres beat the crap out of MyISAM, lol. Seems like Postgres is one of the rare apps which gets faster and meaner with every release, instead of getting slower and more bloated like everyone else.

Also, there is a thing called write barriers, which supposedly could be used to implement fsync-like behaviour without the penalty, if the disk, the OS, the controller, and the filesystem support it (that's a lot of ifs)...

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

Gigabyte should revamp their i-RAM to use ECC RAM of a larger capacity... and longer lasting battery backup... I wonder, how many write cycles those Flash drives can take before reliability becomes a problem...




--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Reply via email to