Sorry but the discussion is going "off-topic" for the original
question, that is: why backup/restore of blobs are so much slower
compared to non-blobs data. I'm also curious about this.

Carlos
Firebird Performance in Detail - http://videos.firebirddevelopersday.com
www.firebirdnews.org - www.FireBase.com.br

Tn> Hi, Alexandre,
Tn> For the sample you gave (NFE), I agree with you, because the
Tn> amount of files that will be generated will be very great and each
Tn> file itself is not so big, probably they will not become a
Tn> problem. And, in this case, they are part of a transaction.
Tn> Probably not, but I´m not sure - one have to make comparisons to
Tn> be sure about the best solution. I told in a generic way,
Tn> specially were we have contracts, photos, and other no transactional documents.

Tn> But, having many NFE (as many as the transactions), don´t you
Tn> agree that these BLOB´s will be a great source of fragmentation inside the DB ?
Tn> And, if I´m sure about my thinkings, as Firebird doesn´t have a
Tn> way to defragment inside the DB, you don´t have a way to resolve this.
Tn> May be, for having a good solution for such kind of business, one
Tn> had to use a MS SQL Server to periodically defragment the DB. Or
Tn> another DB name that has this funcionality. I searched something
Tn> like this at Postgres and I found a command named VACUUM that does
Tn> something like this. Think about all of this, if you want. If have
Tn> to have BLOB´s, I think Firebird is not a good solution for a
Tn> great number of them. My thought, you don´t need to agree.
Tn> Friendly, best regards,Roberto Camargo.