At 01:41 PM 6/10/03 +0100, Artur Anjos wrote:

>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.

Transaction A executes an "insert" verb. A record (say number 639) is stored
on a data page and an index node is added to the primary key index.

Transaction B does a index lookup by primary key. The index scan finds
the index node for record 39 from transaction A and adds it to the
retrieval bitmap. It then processes the bitmap in record number order.
When it fetches record 639, it notices that it creating transaction,
Transaction A, was not committed when Transaction B started. It
examines the record's prior pointer, find none, and ignores record 639.

The record is rejected by versioning system long before it is subject to
boolean evaluation.

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

The frequency of updates shouldn't affect the balance of the tree. That said,
I never got around to putting in bucket recombination code on the naive belief
that data demographics are generally constant. I was probably wrong, but
I don't think it makes a great deal of difference.

Jim Starkey