At 07:24 PM 19/03/2007, you wrote:

>Hi,
>I would like to ask related question ...
>when I create table with ...
>B1 BLOB SEGMENT SIZE x
>then segment size x defines only in memory buffer, where blob data are
>handled /retrieved from data pages or written back/ or it is used to
>define
>size of blob segments in on-disk ?

I think the overall answer to this question should be NO. :-) In
the Third Millenniium, the segment size is irrelevant. To give you
an indication of how "important" the segment size might be for
anything, the default of 80 bytes was decided back at the dawn of
time, merely because 80 bytes was the maximum width of a text screen
in those mystical days.

Perhaps if you are writing a very tight application for Classic
server in C using EmbedSQL, it might become relevant to your
application, if it is using vectors to "pre-package" pieces of a blob
for reasons known best to itself. In the modern age, most wrapper
interfaces take care of blobs for you and *they* decide how large a
packet should be. They don't care what the declared segment size is.

The server itself simply ignores the declared segment size. It lays
down segments on disk in the most economical chunks it can.

>In table row is stored blob_id, which points to chunk of blob
>segments, which are stored in pages on disk.

Actually, the blob_id points to the location of the first
segment...the first segment points to the location of the next....and so on.

>So it is true, that one blob segment can be as large as large is page
>(when page_size is 4K, then one blob segment on disk can be 4K).

It could be, but you would not know (or care). In fact, the whole
page isn't used unless you have the database set up not to reserve
spare space. For one thing, there is always a few bytes on each
segment for the indirection data (where to go to find the next
segment) and the page itself uses a few bytes to identify itself. So
it's one of those myths when people advise you to set a segment size
the same size as the page....

>So when for example I store in blob picture, which is 16KB , then it will be
>split into 4 segments=4 pages each of 4KB ?

No, but it doesn't matter. The engine will make segments of varying
sizes, according to how it can most efficiently store data at the time.

>May be on one data page stored blobs segments from 2 or 3 tables (can
>be mixed) ?

No. Firebird doesn't jumble up data from different tables on the
same pages; nor does it jumble up data from different blobs on the
same blob pages.

>Or one page can hold only blob from one table ?

One page can hold only segments from ONE BLOB. So, e.g., if you
have a table with several blob fields, you won't find the data from
the different blobs on the same page, *except* in the cases where
perhaps there has been space on the data page to store very small
blobs entirely on the same page as the data.

>Is there any minimum alocation for blob (for example 1 page) or if on
>some page (partialy used by other) is unused free space, then this space
>may be used ?

There's no "minimum allocation" but the engine won't mix segments
from different blobs on a single page.

In the general ebb and flow of data in a reasonably active database,
entire data pages or blob pages or index pages could become
free. "Empty" pages are just pages; so a page that stored blobs
before might store data or indexes when it gets re-used, or whatever.

But, if there is spare space on a blob page or a data page that
contains either active data or obsolete data that is waiting to be
garbage-collected, then that space won't be used for some different
record or table or blob, even though its size may be sufficient.

./heLen