Hello, I need comments on that, assuming it's worth the time, of course.
Is this scenario a natural consequence of the architecture, a bug in the
engine or a misuse of the developers?
It appeared in kinobi.performance and I was curious about these results.

C.

Michael Stratmann <Stratmann@...> wrote in message
<392EC554.7EAEDDBC@...>...

> Hello!
>
> Jon schrieb:
> >
> > Hello,
> >
> > I'm having performance problems deleting records from a large table.
> > Each record is small (6 integers) and contains a blob which is one 1k
> > segment.
> >
> > In my prototype I add 20,000 records and then delete them again. The
> > first time through, the commit for the delete finishes in a couple of
> > seconds. The second time through, the commit takes up to a minute.
>
> We (Tilo Arnold and me) have tried it with 200.000 records and 10 kB
> BLOBs. With the performance hints (queries instead of TTable, asc and
> desc indices, set statistics) already implemented. :-/
>
> Delays are going ab to 30 Minutes. An we would like to store millions of
> records. Now we are diskussing alternatives to BLOBs. Personally I
> believe Interbase BLOBs are not a really good idea, if you want to
> delete the BLOBs later.
>
> >
> > I'm using embedded SQL in C++ on a NT machine. The memory usage remains
>
> Me too ;-)
>
> > pretty steady and the cpu usage remains high.
>
> Very similar.
>
> >
> > The database appears to quickly become fragmented. It is unrealistic to
> > perform a sweep after every transaction. How can I improve the
> > performance of the deletion of these records?
> >
> > Jonathan Kinsey
>
> Michael