Just trying to think through this stuff... Not sure of the results of that
process, though :-)

1.) Wouldn't the RAID give me the full bandwidth, anyway? At least for
those tables occupying multiple physical disks?

2.) Again, wouldn't the RAID read from multiple disks simultaneously, thus
being sort of like the same bandwidth as individually scanning individual
disks, but "automatically"? (At least to the extent that the controllers
can accept the I/O?)

3.) Similar thoughts. The RAID isn't JBOD, right? So, I have a firehose of
bandwidth, that's carved up into smaller I/O streams for individual drives
that I never see. And, if # drives sufficient, an additional effect is no
hot spotting.

It just doesn't seem right, at first blush, because we just (from long
practice) tend to immediately think in terms of individual spindles, etc.
It really requires "switching mental gears", at least for me. But, if we
can get 80% of the benefit of agonizing over proper placement of database
objects, but with 20% of the "agony" (metaphorically speaking), we're
interested. Our system just doesn't need the absolute highest performance;
we're not operating like Sabre, or some other huge OLTP system.

DG



"superboer" <superboer7@planet.nl> wrote in message
news:bb790a36.0409150415.70f8ad06@posting.google.c om...
> my two 0.01
>
> haven't played much with 9.4 however
>
> i would use a certain number of dbspaces because of:
>
> 1: paralel dbspace backups
> 2: better use of PDQ ( a scan thread per dbspace )
> 3: (re)loading tables using hpl can be faster when having multiple
dbspaces.
> -- can be faster needs to be tested!!!
>
>
>
> See you
>
> Superboer.
>
> BTW how hard is it to maintain a xx number of dbspaces;