Hi Roberto,
Em 19/4/2012 08:52, Tupy... nambá escreveu:
Alexandre,
At my point of view, I prefer avoid using BLOB fields. First of all, because
these kind of field are not indicated for searches of any kind (most of them
are pictures). Second,
because
normally they have very large
Hi, Alexandre,
For the sample you gave (NFE), I agree with you, because the amount of files
that will be generated will be very great and each file itself is not so big,
probably they will not become a problem. And, in this case, they are part of a
transaction. Probably not, but I´m not sure -
Em 19/4/2012 12:13, Tupy... nambá escreveu:
Hi, Alexandre,
For the sample you gave (NFE), I agree with you, because the amount of files
that will be generated will be very great and each file itself is not so big,
probably they will not become a problem. And, in this case, they are part of
Em 19/4/2012 12:28, Carlos H. Cantu escreveu:
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 -
This query returns 'no current record for fetch operation'
SELECT po.ID, pb.ID
FROM
RPL_PO po
JOIN RPL_POBILL pb
ON pb.PO = po.ID
WHERE
po.ID = ? AND
NOT EXISTS (
SELECT 1
FROM RPL_PO_ITM poi
LEFT JOIN RPL_POBILL_ITM pbi
ON poi.NDC = pbi.NDC AND pbi.INVOICE = pb.ID
MSSQL has two commands of the DBCC that allow to do defragmentation. The
defragmentation is not a garbage collection, but putting all parts of an object
(file or columns, hanging of the level - disc or DB) side by side, in a way
that the reading of data will be almost fast, because all data
In case anyone is confused as to what I'm trying to accomplish, it's an
outer join on line items where both sides match with no NULL items.
If my approach is poor, then I won't have to worry about question about
the exception.
SELECT po.ID, pb.ID
FROM
RPL_PO po
JOIN RPL_POBILL pb
ON pb.PO
On Thu, Apr 19, 2012 at 11:13 AM, Tupy... nambá anhangu...@yahoo.comwrote:
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 ?
Err, no. It's not. I'm not 100% sure what you mean by fragmentation, but
Em 19/4/2012 13:18, Tupy... nambá escreveu:
MSSQL has two commands of the DBCC that allow to do defragmentation. The
defragmentation is not a garbage collection, but putting all parts of an
object (file or columns, hanging of the level - disc or DB) side by side, in
a way that the reading
On 19-4-2012 18:34, Tupy... nambá wrote:
Still something = doesn´t matter if you have the blob field in a separated
table. Since they are all together in a same DB file, they may cause
defragmentation, no one can ensure where at the DB file they will be written
and probably will be written
19.04.2012 20:30, Rick Debay wrote:
I will, after we migrate to FB 2.5.x. Right now we're still on 1.5.6.
This may explain your plan issue. I don't expect you facing it again
after migration.
Dmitry
Alexandre Benson Smith wrote:
In this moment I am doing tests with Carlos Cantu and Dmitry Kuzmenko,
and the culprit so far is my machine, on their machine (both !) the
restore took 3s in mine 10 minutes !
I am testing on ext3 and ext4 partitions and I will make more tests on
another
Rick,
In case anyone is confused
Count me as one of them!
as to what I'm trying to accomplish, it's an outer
join on line items where both sides match with no NULL items.
If my approach is poor, then I won't have to worry about question about the
exception.
What happens with this query?
Em 19/4/2012 16:28, Carlos H. Cantu escreveu:
LC It is a little amazing at time when some things work fast on one machine
and a
LC lot slower on another, but the sort of problem you are seeing I would
check that
LC there is not a problem with the hard disc. I've seen that sort of
14 matches
Mail list logo
