It would help to keep filesizes down if the blockblocksize could be set on a column by column basis.

Roy Lambert

Roy,

> It would help to keep filesizes down if the blockblocksize could be set on a column by column basis.

If you want to do that then you can just bounce each column out so that
it resides in its own BLB file.

Eryk

Eryk


That would work, but it would also mean maintaining the linkages which I know can be done with triggers and joining/setting up master-detail relationships and I would regard as sub-optimal.

Roy Lambert

Roy,

<< It would help to keep filesizes down if the blockblocksize could be set
on a column by column basis. >>

This will happen with the Enterprise Server.  It can't happen with the
existing version without using multiple files per BLOB (or sub-allocation,
which is not optimal), and most people would be against more files.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


OK I'll suffer the waste space then. Its not to bad as long as I use NULLs as well.

What's sub-allocation?

Roy Lambert

Roy,

<< What's sub-allocation? >>

It's allocating using a main block size, and then sub-allocating the main
blocks into smaller block sizes.  For example, you would have a table block
size of 512, and then the columns could each have block sizes that are
smaller than, but still a multiple of, the larger table block size.  The
reason that it gets messy is that you have to share the main blocks among
multiple columns, so you can really experience some severe fragmentation
that can kill any performance benefits that you might have been looking to
gain.  IOW, if you have to read 2 sub-allocated blocks in two different main
blocks (think adding some BLOB column data, and then adding more data later
to the same BLOB column), then you end up reading two main blocks with the
sub-allocation design when you would have only had to read one main block
with the existing design.

--
Tim Young
Elevate Software
www.elevatesoft.com