----- Original Message -----
From: Jim Starkey <jas@...>
Date: Thursday, June 26, 2003 12:25 pm
Subject: Re: [Firebird-Architect] Blobs
Sorry Jim,
improved heart so a little bit late here.
> 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
> >
...
...
>
> 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.
Do not understand clearly but what can be faster than reading all table
(about 20MB) in memory and scanning it there - this is exactly the case
after my space for BLOBs simulated separation (and even more: each table
occupies contiguous space on disk after restore - this is the main
underlying feature I used in my simulation). Still I believe it exists
another tuning to raise slammed performance in my case but no so
effectively and simply for understanding.
>
> 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.
>
It is no mystery in my case I believe but it took a lot of my nerves as
I have participates in all stages of this database and its applications.
As I figured out from your words the question of implementaion of
several data spaces in FB depends on usefullness (my case frequency or
may be something else different, why not).
Of course, I undersatnd FB do not tries to put a lot features for tuning
supposing that in most cases engine will work good. And I like this
approach too. Bur sometimes you need additional parameters for tuning
(even related more with OS features - like different disk spaces) large
database which for small databases are nonsense.