On Tue, 06 Jul 2004 15:27:54 -0400, Chris Browne <cbbrowne@acm.org> wrote:
> "Andy B" <abhousehuntRE-M--O--V-E@blueyonder.co.uk> writes:
> >> I get the feeling that, that regardless 64bit support or not, that the
> >> *concept* of a database which just happens to all easily fit within RAM
> >> isn't one that gets the thumbs down...
> >
> > Oops, I meant to say '*is*' one that gets the thumbs down...
>
> No, to the contrary, having all the data fit easily within RAM is
> quite desirable. One of my coworkers is investigating the
> entertaining possibility of hooking up SSDs to some of our systems to
> entirely eliminate disk I/O for WAL. (The fun part then is to see
> what more can be done with another 3GB of space on the SSD that can
> eliminate a bunch more I/O :-)...)
My experience in tuning Oracle and DB2 is that temp tablespaces are
what belong there. Things that are used when doing joins of large
tables. Honestly, though, it'll depend on your exact application
model. I've also had good luck putting indexes on SSD, because often
you do 3-4 hits of the index before a single seek on the data table.
So the reduction in access time is proportionally larger. I've not
done the numbers recently, but when 10K RPM drives were "the big
thing," I had excellent luck leaving my data tables on 7200rpm drives
that were high-capacity and moving the indexes to 10K drives.
Also a place where the trade offs between duplexing (mirroring with
read-balancing) and RAID-5 can become huge.
Chris
--
| Christopher Petrilli
| petrilli@gmail.com
