Subject Re: [Firebird-Architect] Re: Some benchmarks about 'Order by' - temporary
Author Jim Starkey
Adriano dos Santos Fernandes wrote:
> Vlad Horsun wrote:
>
>> Yes, having all the select list's fields in sorted order is very good
>> thing as it avoid needs to reread it from tables again. This is strong
>> point no doubt.
>>
>> What i mean is that sorted runs contains whole records and during
>> merge phase we must read it from disk and write back merged larger
>> runs. Formally we need only keys to compare and merge.
>>
> Yes, but the whole requested record should be returned to the caller.
>
Nope, only the referenced fields. No reason to drag around a lot of
unreferenced data.
> If they are not written after keys, how you will fast locate it in disk?
>
>
>
No such thing as a fast locate on disk. A disk access averages 6 or 7
milliseconds. A memory reference is 6 or 7 nanoseconds, a factor of
1,000,000. A process cache hit is a nanosecond. Even if the disk page
is sitting in cache, the fetch/release cycle is a great deal more than a
simple memory reference.

A dreadful office-mate named Orin pounded this into my thick head when I
was 17, except that the disk access at the time was more like 20
milliseconds and the memory access (core, gentlemen, core) was in
microseconds. Big difference on a 360/30. Huge difference on a 3 GHz
Opteron.

--

Jim Starkey, Senior Software Architect
MySQL AB, www.mysql.com
978 526-1376