Hi Jim,

> Updates are propagated to the indexes at verb time. This meaning that at

any

> given time the index may reflect values from several versions of the same
> record.
> There really isn't any alternative to this, as a transaction must be able
> to find
> its uncommitted records as well as committed records.

This answer one main concern: how it will use indexes on data that is not
commited.

Having several versions on the same record is something that I was expect.
What it's difficult to me to understand is using an index on a select after
some new records are post.

My english is very poor, so here is an example:

1) Open transaction
2) Post several new records.
3) Select data in a way that we get a mix of this new data and old data
--> We will use an index on this, so AFAIU the indexes must be updated
already, reflecting the new data

.... and at the same time:

1) Open another transaction
2) Select data (same select of the point 3)

So, AFAIU, this transaction will make the engine use the index for all the
data (non-commited records included) and after boolean filter this up
(removing non-commited records).

It will be hard to keep a well balanced tree in situations when records are
post, and most of the time roll-backed.

> If it seems intuitive, you don't understand it, and need to think about it
> some more.

:-) It really seems intuitive.

I will wait if Ann can point me out some doc about this, but your post was
very usefull.

Thank you,

Artur