benedicte_asselin wrote:

>
>
> I use Firebird BLOBs to store documents. My transactions could be
> safely split in two parts, one that stores the document, one that
> shows it to the 'world'. The purpose to have the long part in the
> first transaction which does not prevent any concurrent work and the
> second transaction which must lock some stuff would be very fast.

Your analysis omits the fact that storing new data doesn't block
anything, so no part of the operation prevents concurrent work. It also
omits the fact that copying a blob from one row to another is
approximately as expensive as storing it in the first place. The copy
operation makes a new blob and copies the content to it. There's no way
for two records to reference the same physical blob. There could be if
blobs had use counts, but they don't.

So, yes, you can do what you're proposing, but no, it won't buy you
anything.

Regards,


Ann