On Wed, Jan 02, 2008 at 10:04:53AM -0500, Mark Steben wrote:
> The choices we see are:
[. . .]
I think this is likely to depend almost entirely on benchmarking your case,
and testing the different possibilities. That said, except in extremely
well-defined cases, it's often not a bad idea to make one large RAID anyway,
because you sometimes find that your assumptions about your access patterns
were wrong, and you've optimised for the wrong thing. In that case, the
single large RAID offers greater flexibility, and if your controller is
smart enough, the advantages are small enough that you don't gain enough for
the loss in flexibility.
I also want to point out that you need to test your workload _on 8.2_, and
not make assumptions about disk use based on any experience you have gained
from your production systems. Build a benchmark that looks like your
production traffic, by all means, but don't extrapolate from 7.x to later
versions for I/O information. There have been several huge strides in
recent releases in reducing unecessary I/O, and 7.4 is susceptible to
"checkpoint storms" that make even the most exotic storage hardware fail to
perform well under some circumstances.
Are your estimates of size, &c., based on a fresh load of the data? There
are some lost-space issues in 7.4 that are solved in later releases, so you
might find that some of your estimates of size are a little high. This
matters for I/O, and might also affect your decision.
> Also are there tools out there that monitor disk I/O and disk speed?
Your OS should provide several. The basic ones are iostat and vmstat, but
AIX has its own totally strange variants, and Solaris has some marvellous
I/O tools.
A
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
