|Subject||RE: [firebird-support] BLOB|
|Author||Svein Erling Tysvær|
>>Text, binary, it's all the same to gbak. Try the -g suggestion - if gbak is cleaning out garbage, it's slow.Hi Tim!
>But, surely, the garbage has to be cleaned out sooner or later, and doing it in a backup run is the cheapest way to do it,
>as every record is being visited anyway? (Compared to, say, doing a COUNT(*) to clean garbage, which will visit records it
>doesn't need to, or, worst of all, letting the cost land at random on whichever poor sod next does a query on the table
>with the garbage.)
The original question was:
>Why does it takes so much time to backup / restore (gbak) this table ? (because the BLOB field).If the original database should not be replaced by the restored version, then it is of course sensible to clear garbage. However, I suggested trying this switch since this could be an alternative way to discover whether the problem was (mainly) related to poor transaction handling and not the blob itself.
>Do I have any options to speed up the process ?
I'm actually surprised that Tiberiu notices a problem at all, a table containing 3000 rows and blobs of up to 400 characters should be peanuts for Firebird.