> Rather than replacing just the storage manager, you'd be replacing
> the access methods, buffer manager, transaction manager, and some
> of the shared memory plumbing with our stuff. I wasn't sufficiently
> clear in my earlier message, and talked about "no-overwrite" as if
> it were the only component.
>
> Clearly, that's a lot of work. On the other hand, you'd have the
> benefit of an extremely well-tested and widely deployed library to
> provide those services. Lots of different groups have used the
> software, so the abstractions that the API presents are well-thought
> out and work well in most cases.
True. But after replacement the system as whole would not be well-tested.
"A lot of work" means "a lot of bugs, errors etc".
> The group is interested in multi-version concurrency control, so that
> readers never block on writers. If that's genuinely critical, we'd
> be willing to see some work done to add it to Berkeley DB, so that it
> can do either conventional 2PL without versioning, or MV. Naturally,
This would be the first system with both types of CC -:)
Well, so, before replacing anything we would have to add MVCC to BDB.
I still didn't look at your sources, 'll do in a few days...
Vadim
