Subject | Re: [Firebird-Architect] blobs causes table fragmentation. |
---|---|
Author | Ann W. Harrison |
Post date | 2004-10-04T14:39:18Z |
At 02:44 AM 10/4/2004, Dmitry Kuzmenko wrote:
stored on a data page, preferably the page with the record,
assuming it has space. There's no hard coded limit.
Storing small blobs on page with the record reduces I/O if the
blob data is referenced -- and small blobs are more likely to be
referenced than large blobs.
each of them stores something on page.
based on a (questionable) understanding of the implementation?
It's been some years, but when last I compared our blob
performance with other systems, it was pretty good.
Regards,
Ann
www.ibphoenix.com
We have answers.
>As I understand current behavior, blobs less than 256 bytes areThat's not correct. Any blob that will fit on a data page is
>stored at the same data page, in record.
stored on a data page, preferably the page with the record,
assuming it has space. There's no hard coded limit.
Storing small blobs on page with the record reduces I/O if the
blob data is referenced -- and small blobs are more likely to be
referenced than large blobs.
> If blob is bigger itAs Pavel explained, there are three levels of blob storage and
>is stored at blob page, not data page.
each of them stores something on page.
>There are some systems that store blobs with different size,Do you have any evidence of that? Other than a hypothesis
>so blob data is spreaded between data and blob pages.
>This makes table more "fragmented" and seriously slowdown
>record retrieval if 'select' does not selects blob fields.
based on a (questionable) understanding of the implementation?
It's been some years, but when last I compared our blob
performance with other systems, it was pretty good.
>The suggestion is - to add some header page flag thatLet's be sure we have a problem before rushing to solutions.
>will disable blob storing at data page.
Regards,
Ann
www.ibphoenix.com
We have answers.