Subject | Re: [firebird-support] why Blob is so slow ? |
---|---|
Author | Ann Harrison |
Post date | 2012-04-19T16:57:53Z |
On Thu, Apr 19, 2012 at 11:13 AM, Tupy... nambá <anhanguera@...>wrote:
all data, metadata, blobs, internal structure and state are kept on fixed
sized pages in a single file. Yes, if you're running on a disk that's full
and fragmented, that file will be scattered around the disk, but inside,
it's quite tidy.
collection, except that it's a separate, off-line command.
Good luck,
Ann
[Non-text portions of this message have been removed]
>Err, no. It's not. I'm not 100% sure what you mean by fragmentation, but
> But, having many NFE (as many as the transactions), don´t you agree that
> these BLOB´s will be a great source of fragmentation inside the DB ?
>
all data, metadata, blobs, internal structure and state are kept on fixed
sized pages in a single file. Yes, if you're running on a disk that's full
and fragmented, that file will be scattered around the disk, but inside,
it's quite tidy.
> And, if I´m sure about my thinkings, as Firebird doesn´t have a way toWhen pages are released, they're reused.
> defragment inside the DB, you don´t have a way to resolve this.
>
> May be, for having a good solution for such kind of business, one had toThe PostgreSQL vacuum is similar to Firebird's continuous, on-line garbage
> use a MS SQL Server to periodically defragment the DB. Or another DB name
> that has this funcionality. I searched something like this at Postgres and
> I found a command named VACUUM that does something like this. Think about
> all of this, if you want. If have to have BLOB´s, I think Firebird is not a
> good solution for a great number of them. My thought, you don´t need to
> agree.
collection, except that it's a separate, off-line command.
Good luck,
Ann
[Non-text portions of this message have been removed]