> [EMAIL PROTECTED] wrote:
>
>>
>>As for IDE RAID, IDE RAID is an awesome idea. SCSI disks are just too
>>expensive. Infortrend has a cool IDE to SCSI or Fibre RAID system that
>>rocks.
>>
>>
>
> Obviously, you're caught by those marketing geeks. You're taking
> bandwidth (MB/s)as performance index, which is irrelevant for database
> access. Limiting factor is average access time, and there's still no 3ms
> seek time ide disk. This is not a problem of the interface, it's just a
> fact that (for marketing reasons?) all server grade disks are not
> equipped with ide.
Depending on your application, IDE RAID is a very cost effective system.
Sometimes speed is not important.
> A good raid system will be able to have independend seeks issued on all
> disks in parallel, thus scaling by spindle number (only for parallel
> accessing processes of course, not for serialized access). What you're
> proposing is that the app should parallelize it, instead of leaving this
> to the instance that can (should) do this better.
I'm not suggesting this at all, and clearly you have not read what I
wrote. It is physically impossible for RAID to be faster than its
component disks. Period. To argue that a single RAID system is faster than
separate (comparable) disks managed independently is just not true. I have
even explained why.
Yes, RAID systems do scale by spindle, and seeks are issued in parallel,
but you STILL need to wait for all spindles to complete the operation.
Operations on a RAID system are at least as slow as the slowest disk.
What you are missing is that the RAID is dealing with the multiple drives
as one drive. Two operations have to happen serially, one after the other,
where as with separate disks, the two can happen simultaneously.
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
