Alexandre Kozlov wrote:

>I checked it out. It is not 'abstract'. Nor application was sloppy
>either large low selectivity fields were in database. To check it (I
>mean to simulate different space for BLOB in FB) I create separate table
>for BLOB field, place database files on its own disk and did backup
>restore and after this linear scan operation have increase several
>hundreds time.
>BLOB volume to total volume in my case is approximately 0.999 and
>database size is 60GB
>
>
>

I have no doubt that a test case can be constructed where the blob is
sized so that one record
and one blob fill a data page. This would give very good performance if
the blob were always
fetched and really bad performance if the blob is never fetched. And if
you tuned the table
size to match the cache size, you could construct a test where the
non-intermingled case
where blobs were never fetched would be cache resident where the other
case required
actual disk access. But that test wouldn't tell you a damn thing about
performance in situ.

But since large blobs generally have a blob root consisting of a single
blob pointer page
number, it should have same (or better) performance than your scheme of
putting the blobs
in a separate table.

Like I said, when I had the chance to do it all over again, I did put
blobs in a different
data space. Still, I don't think Firebird would see much benefit from a
change. But
I could be wrong. But I am sure that if you're seeing a "drastic"
difference in performance,
you should take a much closer look at what you're actually measuring.