Re: The old raw devices chestnut.

In message <407a7113$0$4574$afc38c87_at_news.optusnet.com.au>, Noons <wizofoz2k_at_yahoo.com.au> writes
>"Jim Smith" <jim_at_jimsmith.demon.co.uk> wrote in message
>news:dS4PuczgskeAFwJq_at_jimsmith.demon.co.uk...
>> This question was prompted by a thread on the a postgres mailing list
>> during which someone (Gregory Williamson) claimed
>>
>> <quote>
>> raw devices, at least on Solaris, are about 10 times as fast as cooked
>> file systems for Informix.
>> <quote>
>>
>
>
>Let's see first if we can all understand what the heck
>is meant by "faster"?
>
>Is it faster I/O requests?
>Or faster I/O overall?
>Or less CPU used?
>

None of the above. A faster response and or throughput from a user point of view.

>Here is IME:

>
>1- Raw does not make for "faster" I/O. I/O speed is defined by
>your hardware (disk + controller) and raw or cooked means nothing
>in that context.
>

>2- Raw produces overall faster I/O response, all else being equal.
>
>3- However, this can be MUCH faster, or slightly faster.
>
>Explain:
>
>If db is reading off the file system buffer cache, then it is
>eminently STUPID to claim "file system I/O" is faster: there is
>no I/O in that case, just in-memory access!

But it will give a faster response therefore "file systems are faster".

But, database blocks will often be buffered in the db buffer cache so the file system buffer may be irrelevant or even an overhead. I vaguely remember on VMS it was recommended you disable disk caching and used oracle's buffer cache.

-- 
Jim Smith
Because of their persistent net abuse, I ignore mail from
these domains (among others) .yahoo.com .hotmail.com .kr .cn .tw
For an explanation see <http://www.jimsmith.demon.co.uk/spam>