Hello, Jim!

Tuesday, October 5, 2004, 6:09:35 PM, you wrote:

JS> page number), and record number on the pointer page. If blobs are moved
JS> out of record number space, then either the size of the blob pointer
JS> size must be increased or we get stuck with an architectural limitation
JS> of one blob per page.

No problem. Right now we can get 2 example cases:

5K blobs at 4K pages and 5K blobs at 8K pages.

first will store blob on 2 pages for each record.
second will store blob on same page with record.
I mean, we always will have production databases that
have blobs greater than page size - and, here is
that architectural limitation.

JS> It may have to be increased to accomodate 40 bit
JS> record numbers, but I don't know whether anyone has gone there yet.

It's not sufficient right now. Sinse we don't have 40-bit record
numbers we'll have same architectural limitation for blobs - see
first case above. Really big tables almost never have blob columns.
But, storing blob in record for big table can raise notorious ~36GB
table limit much earlier than in case 2 (blobs out of data page).

JS> An architectural limit of a single blob per page would be a performance
JS> and operational disaster, wasting a cache slot and data page of 4096
JS> bytes to hold a one byte blob. It is so unthinkably bad to preclude
JS> serious discussion.

see first case above. second case is much worse, if you seen my test
results.

JS> Somethings blobs are used to big things and sometimes blobs are used
JS> when the worst case size of a character field isn't known. Street
JS> addresses, for example, are often stored as blobs for no reason other

This isn't worst or best - there are lot of different binary data
that can have different size. For example, web applications can
store gif images - big pictures or small thumbnails, etc. Right now you can't
predict how large or small they will be and how they will affect
performance for choosen database page size.

So, what we can -
do nothing praying for 40-bit record numbers. Current issue (with
blobs) will be forgotten until some user will find it and report, or
Borland will unambiguously fulfill this behavior
(hard comment? maybe. but we already have at least temporary
system tables in IB 7.x - this idea was born here, but Borland
made it, alone).

or

1. make desired flag in header page for current ODS without any
other incompatible changes.

2. after point 1 in FB 2 code add column to rdb$relations and DDL extention to
allow blob storage management at table level

3. after adding 40-bit record numbers (in FB 2 too) extend the same for blobs
stored outside data page.

Need to say that while I'm totally agree with all you said, we can't
tell users how they must design their databases (blobs in separate
table) or what size of blobs they may store in db or not.
Also we can't include Human Brain v 0.9 into the engine, in order
to manage all kinds of data perfectly for all productional
databases. In that case there must be some handles to allow
users tune their databases.

--
Dmitri Kouzmenko