Subject | Re: [firebird-support] Choosing a blob segment size |
---|---|
Author | Ann W. Harrison |
Post date | 2005-02-08T17:02:51Z |
Olivier Mascia wrote:
handle 64K right.
has minimal structure - just a two byte length - and the system will
pack the segments regardless of page boundaries. If your first segment
fills 14.4 pages, the next will start on the next free byte of the 15th
page and continue from there.
With records, the system won't write a new record on a partially filled
page unless there's room for the whole record - or the record,
compressed, is still larger than a page.
Blobs are different. If you've ended one segment part way through a
page, the next segment will follow it immediately, even if that segment
won't fit completely on that page.
Hope this helps,
Good luck,
Ann
>Yup, except that I'd use 32K because I don't trust all the utilities to
> In the context of using the C-API and segmented blobs ...
> what would be a wise guess as to which blob segment size to choose ?
>
> Would you go for simply the largest segments one can write at a time (n
> segments of 64K - 1 bytes plus one last segment for the remaining
> bytes) ?
handle 64K right.
>There's no particular benefit to fitting segments on pages. A segment
> Would you go for something just wide enough to fit on a database page ?
> But then how to compute the max segment size that would fit on a given
> database page size ?
has minimal structure - just a two byte length - and the system will
pack the segments regardless of page boundaries. If your first segment
fills 14.4 pages, the next will start on the next free byte of the 15th
page and continue from there.
With records, the system won't write a new record on a partially filled
page unless there's room for the whole record - or the record,
compressed, is still larger than a page.
Blobs are different. If you've ended one segment part way through a
page, the next segment will follow it immediately, even if that segment
won't fit completely on that page.
Hope this helps,
Good luck,
Ann