> I don't want to waste a lot of time in conjecturing this, since it's not
> something that would (should) be done to production data and wouldn't be a
> requirement for any transaction-capable DBMS. Why is it an important test
> for you?

Because if it's slow in a situation like this one, I could expect to be slow
for something that's a requiement for a DBMS.
And I know that' sometimes it happens to modifiy the same record twice in a
single transaction. Think of an user editing a record, posting it, not
ending the transaction, and changing it again.

> How would the engine know that? It still has to locate each delta record
> by walking both the cache and the original versions. On your first pass,
> it attacks the data in natural order; on subsequent passes it has to
> compare two sets of data, each with its own natural order. When a query is
> slow, the time cost is a matter of navigation, not the time it takes to
> alter data.

It does not need to locate each delta record, since it's changing data
changed in current transaction, so it's changing only the current record.


Adrian Roman