Maryse,

It is DEFINITELY good to use different locations in a SAN environment,
but with the caveat that you have to understand the physical mapping
of the filesystems.  There are ranks of drives, parity groups, etc.
that are all mapped out by the volume manager.

Companies will often take the largest disk drives possible for the SAN
(because of cost of expanding beyond the SANs capacity based on the
number of physical disk drives it can hold), and those drives are
almost always slower (10,000 rpm, instead of better 15,000 rpm
drives).  System Administrators will typically make everything RAID 5
(instead of RAID 1+0 or RAID 6) because it is easy and because the SAN
vendor tells them that there will be no performance degradation due to
large caching controllers.  This is just a performance problem waiting
to happen.

If you are lucky enough to be in the process of purchasing a SAN then
there are things you can do to help (see the next paragraph).  The
controller cache on most SANs is mirrored (so you really only utilize
half of what is installed, and most have algorithms (sometimes
tunable) to using a ratio (often fixed but sometimes dynamic) to split
(provision)  the usable cache between reads and writes.  There is also
benefit to locating filesystems in the middle of the physical device -
something that is hard to do when you have everything aggregated into
a few large locations.  So, there are a lot of opportunities for
misconfiguration.

For example, I spec'ed out a high-end SAN for a large company a few
years ago.  The salesperson convinced them that 16 GB of controller
cache was overkill (and sold them 2 GB), and that the larger drives
(that were also more expensive) were more than sufficient.  I fought
to get the faster drives for the Ingres configuration and won.  The
Sys Admin told me that there was no way to saturate the controller so
during JD Edwards / Oracle user acceptance testing we ran one hundred
concurrent disk benchmarks (free download at http://www.comp-soln.com/WriteBench.zip)
on our faster Ingres drives. We saturated the drives and after two
upgrades we were finally at 16 GB of controller cache and all was
well.  The Oracle guys using RAID 5 on the slow drive had performance
problems and ended-up getting a configuration that was identical to
ours.

Look at the disk layout on the top of page 6 in the presentation at
http://www.comp-soln.com/Global_Support.pdf for a diagram of the
system described above.  It had three Ingres installations (Americas,
Japan, and Hong Kong / China).  There were eight locations for both
data and checkpoints (for parallel checkpoints), which were rotated
(e.g., data location 1 and checkpoint location 8), with other high I/O
locations (transaction log file and sort locations) on different
drives.  This approach provided an extremely balanced I/O workload and
was highly resilient in the event of a disk loss (an added precaution
above and beyond RAID).

Anyway, a long-winded explanation to demonstrate that it does make a
difference.  There are several variables so it is impossible to
provide a precise range for the amount of difference that will be seen
in a good configuration versus a normal configuration, but it is
noticeable, especially under load.

Something else to keep in mind is that it still makes sense to use
multi-location tables in Ingres, even if you're using RAID 0
(striping).  This is because of the way Ingres knows exactly where to
look for the data based on the number of locations and the TID.  This
simple change can make a 1% - 3% difference in a busy benchmark on
high-end equipment (such as what you find in vendor's performance
labs).

Hope this helps.

Chip