Alexandre Kozlov wrote:

>Hi Daniel,
>it's not full true. Because really BLOB information usually being much
>much bigger that scan information always slow down scan process
>drastically. 'Read ahead' feature of OS doesn't work in this case as OS
>have to issue physical read practically for each DB page.
>
>
>

I think that if you look you will find that only the blob root -- either
a very small blob, a vector
of blob page pointers, or a vector blob pointer page pointers -- are
stored on data pages. In
fact, the larger the blob, the less is stored on the data page. I don't
know where the notion
that blobs "drastically" slowed down scans, but I'm sure everyone would
like to see your
data...

A read-ahead feature is not only feasible, it was factored into the
original design. Since all
significant retrievals are index bitmap driven, the engine knows before
starting the actual
record retrieval operation exactly what data pages are necessary. On
those rare operation
systems that support true asynchronous operation, it would be completely
feasible to to
issue asynchronous reads for all targeted pages, then processes the
pages in the order
they arrived, presumably optimized by a smart disk controller taking
advantage of rotational
position and seek ordering.

The Interbase precursor -- Rdb/Eln -- was actually designed to run
inside DEC's HSC
disk controller to do exactly these things.

Unfortunately, neither Unix-based operating systems nor IDE disk
controllers are nearly
sophisticated enough to support these types of operations, and the
required page handoffs
from pointer to data pages make it infeasible for the classic architecture.