[This followup was posted to comp.databases.postgresql.hackers and a copy
was sent to the cited author.]
A few thoughts:
1) There may be reasons why someone might not want to use RAID. For instance, suppose one wants to put different
tableson different
drives so that the seeks for one table doesn't move the drive heads away
from the disk area for another table. Also, suppose someone wants to use a particular drive for a particular
purpose (eg certain indexes) because it is faster at seeking vs another
drive that is faster at sustained transfer rates. Also, someone may want to span a drive across multiple SCSI
controllers. Most RAID arrays I'm aware of are per SCSI controller. I think it is fair to say that there will always
beinstances where
people want to have more control over where stuff goes because they are
willing to put the effort into more subtle tuning games. Well, there
ought to be a way.
2) Some OSs do not support symlinks. The ability to list a bunch of
devices for where things will go would be of value. Also, if you aren't putting your data on a real file system (say
on
raw partitions instead) you are going to need a way to specify that
anyway.
In news:<394A556A.4EAC8B9A@alumni.caltech.edu>,
lockhart@alumni.caltech.edu says...
> o the ability to split single tables across disks was essential for
> scalability when disks were small. But with RAID, NAS, etc etc isn't
> that a smaller issue now?
> o "tablespaces" would implement our less-developed "with location"
> feature, right? Splitting databases, whole indices and whole tables
> across storage is the biggest win for this work since more users will
> use the feature.
> o location information needs to travel with individual tables anyway.