Re: back-bdb IDL limitations

["David Boreham" <david_list@boreham.org>]

> Is it so because of the recovery overhead can be huge ?
> Even so, transactions seem to be indispensable to situations like 
> incremental slapadd.

No. With transactions and locking off and some decent optimizations
on the database building code you should be able to achieve many 1000's of
entries per second. With transactions and locking on throughput should
be much lower. Hence unless you are building an enormous database,
in the event of a failure, it'll be quicker to treat the entire database 
build
process as one big transaction. If it fails, delete the files and re-start.
I agree that you will be able to show that for some size of database
and some probability of failure, it will be better to transact on a finer
grain. However my feeling is that those sizes and probabilities will
fall outside the envelope for most deployments. You'd need to be
seeing database build times on the order of many hours : which would mean
many tens of millions of entries.