> > new way for a faster and better database engine. I know (and agree)
> > that it not is priority for next year(s?). But it is
> interesting, and
> > is prabably good remember it during development, and not
> write (in future)
> > features which close this good way.
>
> I would be very surprised to see any significant change in raw vs.
> filesystem i/o on modern file systems,
Beleive me, the difference is substantial.
When you test this you will typically need DB's, that
are larger than your OS file cache.
Second you need to add the memory, that is used by the OS to
cache the DB files to the DB buffer cache when testing raw devs.
Typically you will also use async IO.
One other advantage is, that extending/creating a big raw device
is way faster (takes subseconds for 2 Gb) than creating a big file
(takes minutes). This is especially a pain during restores.
Restores to raw devices (including device/file creation)
are typically only little slower than the backup.
Andreas
