Subject Re[2]: [Firebird-Architect] blobs causes table fragmentation.
Author Ann W. Harrison
At 05:00 PM 10/4/2004, Dmitry Kuzmenko wrote:

>Client components don't differ is this large blob or not.
>Remembering BDE, using SELECT * FROM TABLE (it's way to hell,
>of course)

Right. I'd like the system to be fast for people who use their
heads. Asking BDE to SELECT * FROM TABLE is right up there with
SELECT COUNT (*) FROM LARGE_TABLE in terms of useful coding
practices. When we face a choice that will hurt a careful
program to help a stupid one, I think the world is improved by
not encouraging stupidity.

>So, it depends on client components/driver - it load all blobs
>into cache or doesn't load any blobs at all.

I would expect, depending on the component and the application,
that if you asked the component nicely for the customer's name and
address, that it would return the name and address, even if the
address were a blob. If you didn't ask for the compromising
videos of the customer (a large MPEG blob), the component would
not return the contents of that blob.

The way the system currently works, the small address blob will
probably be on the same page as the name, a significant net gain.
The page array for the MPEG may be there as well, but the data
pages that hold that blob won't be loaded.

>Why not? SQZ_block in yaffil was made on the same basis. It was
>made (very little code changes), tested, and produced good results.

Probably I'm wrong and we should compress blobs, given all the
changes (availability of code, speed of processors) since that part
of the system was designed.